Re: Ada95 OOP Questions

[ecn@explorer2.clark.net (Eric C. Newton)]

In article <JSA.96Aug13221742@alexandria> jsa@alexandria (Jon S Anthony) writes:

<We were discussing multiple-dispatch.>

   Basically, because no one knew what the "right" dispatch policy should
   be in such cases and no one had any intention of putting in something
   like the MOP.  So, it didn't happen.

Yes, multiple argument dispatching is a difficult thing to reason
about, and I'm just a lowly mortal.  Ada's syntax only suggested such
a thing to me.  I figured someone else worried about making it work
safely.

   I see no reason why _passive_ entities (the so called objects for
   either of the above) should look like they are acting or being
   commanded to act.  If you want that then use an activity which in Ada
   would be modeled by a task:

Yes, a task is a good model for an active thing.  Perhaps I should
have said "This is a Person.  It manages person-state, and satisfies
person-services, as listed in the encapsulated person class."  But,
you would say: "This is a person.  It represents the private state
used by the services encapsulated in the person package."  

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.

   >    package Matrixes is

   Shrug.  And?

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.  Matrixes encapsulates Matrix *and* Vector
types.  I can list the Matrix and Vector operations willy-nilly within
this namespace.  In C++/Modula-3 I must list the operations on the
private state of Matrix within the Matrix class.  I must list the
operations on the private state of Vector within the Vector class.
There is visible association of dispatch methods and type.

*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.

I'm just trying to cross the bridge between traditional object
languages and the approach taken by Ada.  They share almost no
vocabulary and use different words for similar things, and they look
completely different.

Of course, smalltalk lets you put a method anywhere, at any time,
right?  You rely on the browser to provide the "grouping of methods."
So there's a tradition of other mechanisms, too.

   > I keep trying to see packages like I see objects and it just doesn't
   > get any easier.

   That's because they aren't objects/classes.  They are orthogonal constructs.
   Classes are classes (T'Class, e.g.), objects are objects ( Obj : T, e.g.)

Yes, they are orthogonal, but you *almost* always want a class
encapsulated.  So in other OO languages, I get some encapsulation with
a class, in Ada I have to create a new package.  On the other hand,
there is no need for the C++ "friend".

   > Namespaces are good.  Objects are good.  Yes, Ada 95
   > has both, but it is pretty good at hiding the objects.

   Huh?  An object is quite explicit and obvious:

       X : T;  -- X is an object for any type T.  Pretty clear and obvious.

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.

   The use of "tagged" is indeed controversial...

It encourages me to think of Ada's mechanisms as a way add in
dispatching, rather than a means for organizing my runtime
architecture.  Dispatching/polymorphism is a powerful tool for
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.

-Eric

-- 
Eric C. Newton        Software Reuser.
Newton Consulting     Look at all the code I didn't write today!
ecn@clark.net	      http://www.clark.net/pub/ecn/home.html