[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When should objects be used?



> > OK, you need to help me out here - what is the difference between
> > direct graphics objects and object graphics objects?

i'd encourage anyone to read about OOP before looking at this area with
IDL.  While no expert, what experience i do have in this area before
beginning with IDL a year ago made me realize from the start there more
advantages to OOP than is implemented in RSI's attempt to incorporate
this "facility".  Unfortunately, imho, I think this is where it goes
wrong - Objects aren't an add-on but should either be the basis of a
language or not.  I just really don't think learning how to program with
objects in IDL as a first exposure is a good thing. go read some on
object design. :)  it'll take less than a few nights of reading to
understand the basics and things will begin to make sense.  but also
some things in idl will just not make sense ;)

> graphics. (There are also things you *can't* do in object
> graphics that can easily be done in direct graphics. For
> example, you can't currently label a contour line with
> its value in object graphics.)

The first wall I came up against is that I couldn't incorporate a draw
widget into a GUI canvas of buttons, menus, etc.  It seemed that you had
to have a specialized window dedicated for plots.  Anyone manage to do
this in object graphics?  I'd be interested to know, although I did end
up using direct graphics for maximum speed.

Being familiar with several visual object languages, it wasn't
immediately obvious to me how a widget object packer worked either. 
view->scene->window, fine, but i couldn't work out how to arrange
buttons, labels, draw widgets etc into this and there weren't any useful
examples in the documentation that's for sure.  maybe it's just my only
dedicating 2 days to this area - but why is there a IDLgrPlot object,
but no textbox, slider or button objects?  I could never work this out
and saw this area as somewhat of a sad joke given my previous experience
in Python, c++ and ArcView.

> One of the things that is holding object graphics back,
> in my opinion, is not that they are so hard to use (it
> takes about a page and a half of code to reproduce the
> direct graphics PLOT command, e.g., see XPLOT), but that

personally i don't think they _need_ to be this difficult.  they've just
been made that way because it's not object designed from the ground-up.
:(  there are better ways to learn about objects.  Python is the best
I've seen - alot friendlier than Java for starting out.

> But on the other hard, objects are really NICE! Each
> object's properties are "sticky" if you like. If I
> create a plot object, for example, and tell it I want

i think if we begin using accepted terminology such as classes,
instances, attributes, methods, etc it'll make it easier on the people
trying to pick the stuff up from external-IDL sources.  just my opinion
though.

> it to draw its data in a green line with red symbols,
> it is going to draw its data like that forever. I don't
> have to set a COLOR keyword every time I want it done
> that way. I just tell the object to draw itself and it
> knows what it should do.

i think an important thing here is that we can move away from that darn
concept of attaching structures to the user defined value of widgets. 
That's just a work around the problem that gui programming is most
suited to an object approach I feel.  when you have some decent objects
to start with that is...

> We can just write our own objects to do whatever we want them
> to do.

but i would cautiously point out that we are limited by the foundation
classes and subsequent class heirachy RSI have provided us with.  so my
advice isn't to sway anyone here into using objects or not, more to take
in wider view of the field, then make up your own mind on RSI's OOP
attempt.

cheers, nick

-- 

Nick Bower
Space Science and Engineering Center
University of Wisconsin, Madison, USA
Phone: (608) 265 8007
Email: nick.bower@ssec.wisc.edu
Web: http://arm1.ssec.wisc.edu/~nickb