Re: object newbie

[Martin Schultz <martin.schultz(at)dkrz.de>]

Pavel,

   these are valuable comments. However, I disagree that objects are
only useful for
N >= 50 as you indicate. Especially when using inheritance, they have
tremendous power
even for N = 1 if you like some uniform access to "things" that belong
to the same category 
but may all be a little different. Certainly you are right that
structures still have their
value, and you don't need an object for EVERYTHING in IDL. Yet, I have
the feeling that
your comment misses the point in answering Chip's question, and that
this is probably
because the question itself is flaky. I haven't pondered over this day
and night, but
I dare to say that you made something wrong when you need to know the
fields that are
stored in the object. Object oriented programming does require
substantial twists of 
the sequential programmer's mind in terms of program structure. As
always, the design of a 
program is the most important step in programming, but for objects it is
even more
important. Every object field (structure element) that you want to
access from outside
must be explicitely interfaced for a reason (encapsulation). All other
fields should
be regarded as private properties of the object for use only by the
object itself.
If you need access to object fields, the GetProperty, SetProperty
convention also
allows you to distinguish between Readonly and Writeonly access, simply
by including
or emitting respective keywords. Sure, OOP requires more typing than a
classical program,
but so far I still think I am rewarded in the end by a product that is
much more powerful
than a classical program of similar complexity. And if I had wanted to
include all that
power into a classical program, I probably would have had typed at least
as much.

Cheers,
Martin


Pavel Romashkin wrote:
> 
> I have a feeling that Chip's question is not quite answered by the dump
> truck full of technicalities the group readily poured out. It looks to
> me that the question is, "my object is just a structure but it is hell
> of a lot harder for me to use it than a regular structure".
> I would say that if all you need is the data and there is one instance
> of it, you do not need an object. The whole idea is that object is a *reuseable*.
> For example, you have one data processing task. You have a vector map
> and an overlayed image. You want to be able to access the data for that
> image only. Might as well write plain code for it.
> Now, you have the same map, but 50 images that will be processed
> similarly. In this case, if you write an object, then you can write the
> "25 methods" only once, and very elegantly call those methods in your
> widget event processing code. This way, you have intact data and a set
> of actions (methods) you can perform on that data. And, if you happened
> to aquire more bands of the image(s), you do not need to alter the code.
> You just add more objects that use the same methods. On the other hand,
> if you create a structure (or array of such), then you can't as easily
> add another elements to it. Actions (code that modifies the data) tend
> to become less organized (because they are not linked to data), and
> event handlers become very complex.
> This is not to mention inheritance, which simplifies dramatically
> operations on data that are derivative or daughter to the main object class.
> Cheers,
> Pavel
> 
> Chip Sample wrote:
> >
> > I must admit that based on comments from this list, I have experimented with
> > the object features of IDL for the past week or so, and have implemented
> > them in a few places in a fairly big widget code I have written.
> >
> > My initial observations are that there seems to be less of a temptation to
> > use common blocks when objects are used.  On the other hand my first
> > impression was that an object is a structure whose fields can not be
> > accessed until you write additional "methods" to get at each and every damn
> > one of them.  So my object was littered with about 25 "methods" just so I
> > could pry the data out of the object.
> >
> > I eventually came on a work around to write a "proto_object" with a method
> > allowing you to pass a string containing a tag name which returns the
> > contents of the field with that tag name.  This "proto_object" is inherited
> > by all other objects I create just so I can use this method.  Along the way
> > I found that the TAG_NAMES function in IDL doesn't work for objects so I had
> > to create one.  It basically copies the object structure into a regular
> > structure so the TAG_NAMES can be used.
> >
> > Am I making this too hard?
> >
> > Chip

-- 
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
[[ Dr. Martin Schultz   Max-Planck-Institut fuer Meteorologie    [[
[[                      Bundesstr. 55, 20146 Hamburg             [[
[[                      phone: +49 40 41173-308                  [[
[[                      fax:   +49 40 41173-298                  [[
[[ martin.schultz@dkrz.de                                        [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[