Re: Ada95 OOP Questions

[jsa@alexandria (Jon S Anthony)]

In article <dazq3xu7ul.fsf@explorer2.clark.net> ecn@explorer2.clark.net (Eric C. Newton) writes:

> My problem is that I like having *BOTH* a person package *AND* a
> person class encapsulation mechanism.  I can live with just one or the
> other, but I like both.

What does this give you?  Certainly you can nest a person "class" package
inside of a personS package.


> The point of the (deleted) example was to show that a package is just
> a namespace, and that multiple classes can live in that namespace, and
> that the features of the class do not need to be visibly associated
> with the dispatch object.

Yes.  And I "shrug" to that.  Same sort of situation for Dylan or
CLOS.  Of course, that doesn't make it "good" by definition or
something.  Just that this is a specific design choice balancing
various requirements, reasons, etc.


> *I* know I can create little packages for each class.  *I* know that
> they are equivalent.  I think there is a case to be made that the Ada
> approach can be beneficial in some cases (such as in tightly coupled
> classes such as Matrix and Vector).  BUT, I think I would miss the
                                              ^^^^^
> textual grouping and extra encapsulation level

Maybe.  But I see the operative word here as "think".  What's really at
issue is "this is what I am used to".  Which is a definite point, but
can also close off potentially "better" alternatives.


> I was just pointing out that Objects need not be encapsulated with
> respect to each other and that dispatching is not obvious at the call
> site.

Actually, dispatching is _more_ obvious at the call site than in
something like Eiffel or C++.  That's because dispatching is a local
thing - _indicated_ at the specific invocation.  In C++ or Eiffel you
indicate this dispatching (virtual in C++) or non dispatching (frozen
in Eiffel [this is not quite the same, but prevents dispatch])
behavior back in the class definition.  Also, once it's made it is
pretty much fixed (you have to go back and hack the class to change
it).  In Ada you pick what you want at the particular call site and
indicate it.  In general this is pretty explicit:

   A : T;

   Op(T'Class(A));  -- Dispatch
   Op(A);           -- No dispatch

or

   A : T'Class; -- Typical of a class wide operation signature which
                -- will dispatch internally for specific behavior

   Op(A); -- dispatches...

In any event for any call, you only need to look around _locally_ to
see if the parameter to the Op is classwide - if so the Op dispatches.
In the other two example cases, you have to go back to the class
definition to be sure.


> abstraction.  I suppose that Object-Oriented programmers like myself
> are simply looking for the comfortable encapsulated, abstract,
> polymorphic entity they know and love in a single construct.  This
> discussion has helped me understand the Ada approach, and maybe it
> will help me explain it to others.

Sounds good to me!


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com