| Re: Object based/oriented IDL ? Ever likely ? [message #5952] |
Fri, 22 March 1996 00:00 |
Ken Knighton
Messages: 44
Registered: May 1995
|
Member |
|
|
Paul Schopf <schopf@gsfc.nasa.gov> wrote:
> Now if you want to discuss encapsulation and inheritance, I agree,
> IDL is not OOP, but these are data structures, and they are very
> easy to use, and you can write functions for them, etc. etc.
IDL is not an OOL, but it does have a number of features that
make it possible to do things traditionally supported by
OOLs although perhaps not with the same elegance:
1) Polymorphism
a. Functions/procedures can be called with a variable number of
formal parameters.
b. Since identifiers are dynamically typed, a single func/pro
can be devised that performs an operation on a variety of
input argument types.
2) Inheritance
a. Keyword inheritance (_EXTRA) can be used to allow a wrapper
routine to "inherit" the capability of another routine
and add functionality to it. For example, one can write
wrapper routines to the PLOT procedure that do some
other things but allow the calling program to utilize all
of the present and future PLOT command keywords without
having to keep track of all of them.
b. Virtual funcs/pros: Use of the EXECUTE, CALL_PROCEDURE, and
CALL_FUNCTION routines allows a programmer to set up
"classes" that have user replaceable member routines by
allowing the calling program to pass the names of the new
member routines into the "class" via arguments or to place
them into a common block for the "class".
c. Various keywords to widget routines give the programmer the
ability (with the above techniques) to do almost everything
that OOLs do as far as widgets are concerned. This includes
the ability to have constructors/destructors (notify_realize
and kill_notify), different instantiations of a class (this
is what an object is) by keeping a widget's information in
a state variable rather than a common block, encapsulation
of data in a widget's state variable, and etc.
3) Encapsulation (data hiding)
IDL doesn't have global variables (except for system variables) and
therefore automatically has data hiding unless one uses common blocks.
Even so, common blocks are only "public" to routines that reference
the common block. A judicious use of modular programming techniques,
naming conventions, the @ command to include "header" files, and
other techniques give the programmer the ability to do a pretty
good job of encapsulating data in the module that needs it. If
there are going to be various instantiations of a module (objects),
then it is possible to use widget state variables or handles to
provide data encapsulation at the object level.
4) Operator overloading
IDL doesn't support this. Although it might be convenient to
overload operators as far as command line users go, from the
application developer standpoint (the guys that use C++, SmallTalk,
and other OOLs), many feel that operator overloading is a bad
practice and attempt to avoid it.
It is unfortunate that some of IDL's truly powerful features tend to
be hidden or unknown to the majority of users. It is also unfortunate
that RSI doesn't use them in most of the code they supply with IDL.
It would be nice to have a bunch of tools supplied with IDL that were
written in IDL using excellent software engineering practices and
the powerful techniques that are already available in the language.
That way, users would have examples to go by when creating their own
cool software.
Finally, IDL is used in two ways: interactively and for application
development. I feel that many improvements can be made for each mode
of operation, but an improvement for one mode is not necessarily a
desirable improvement for the other. I look at IDL from an
application developer standpoint.
>
>
> BTW, a 3000 line IDL app is EXTREMELY long.
>
Sounds rather small to me, but that's the way it goes with
perspectives. :-)
Ken Knighton knighton@gav.gat.com knighton@cts.com
General Atomics
San Diego, CA
|
|
|
|
| Re: Object based/oriented IDL ? Ever likely ? [message #5961 is a reply to message #5952] |
Thu, 21 March 1996 00:00  |
Paul Schopf
Messages: 2
Registered: March 1996
|
Junior Member |
|
|
Julien Flack wrote:
>
> I am very impressed with a number of features of IDL. However, I think
> that its lacking support for structure (primarily data structures) due to
> its historical affiliation with Fortran (no flames please). This weakness
> becomes noticable when you reach a 3,000+ line application (IMHO).
>
> I think that a version of IDL using object based/oriented technology would
> be immensely powerful and would reach a far wider audience. Is there a
> desire for OO technology in the scientific community, or is Fortran still
> predominant ? Have RSI made any moves in this direction ?
>
> Any news, views and gossip welcome ...
>
> --
> Julien.
Am I missing something here? I enclose a snippet of a code which
I believe does have structures (Very similar to Fortran-90--no more flames, please)
; Grid_Index : an i,j pair
Gi = { GRID_INDEX , I: LONG(0), J:LONG(0) }
; Point_t: an (x,y) pair
pt = { POINT_T, X: 1.0 , Y: 1.0 }
; Poly8_t number of points, then space for up to 8 points
P8 = { POLY8_T, N: LONG(0), VERT: REPLICATE(pt,8) }
; Grid record, key index, Grid index, polygon, area
GR = { GRID_REC, ID : LONG(0), G : Gi , P: P8 , AREA : 1.0 }
plot,[-180,180],[-90,90],/nod
nrecs = LONG(0)
openr, iu, 'grid1.db', /f77,/GET_LUN
readu, iu, nrecs
rec = gr
for i=0,nrecs-1 do begin
readu, iu, rec
plots, rec.p.Vert(0:4).x,rec.p.Vert(0:4).y
endfor
free_lun,iu
end
Now if you want to discuss encapsulation and inheritance, I agree,
IDL is not OOP, but these are data structures, and they are very
easy to use, and you can write functions for them, etc. etc.
BTW, a 3000 line IDL app is EXTREMELY long.
--
Paul Schopf mailto://schopf@gsfc.nasa.gov
Coupled Climate Dynamics Group/971 http://ccdg.gsfc.nasa.gov/~paul
NASA Goddard Space Flight Center
Greenbelt, MD 20771
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
