Re: Eiffel and Java + Ada dispatching

[jsa@alexandria (Jon S Anthony)]

In article <55p0i3$2u4@tjnews.is.s.u-tokyo.ac.jp> jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel) writes:


> >You are correct in saying that there is no semantic difference between
> >unique names and overloading. However, just because there is no semantic
> >difference don't suppose that it doesn't play a critical role in how the language
> >is defined. 
> 
> Yes, it does. For example by making things much more complicated;-)

Let's look at this in a different way.  Suppose that we didn't have any
overloading.  What would happen to the object model?  Suppose we have

    type A is tagged ...
...
    type B is new A with ...
...

    type P is tagged ...
    function Op ( x : P;  y : A ) return Something;
...
    type C is new P with ...
    -- Here we want to "refine" Op based on y having type B (covariant thing)

Now what?  Does C inherit Op from P?  If so, is Op covariant on the
second parameter?  Suppose we want to refine it, then what?  I suppose
we would need to introduce something like the "redefines" clause of
Eiffel lest we have name clashes.  Also, at the time we would've been
doing this, system validity issues associated with covariant
operations would be well known in the field.  What do we do about that?
- especially since one of the fundamental precepts of Ada has always
been to avoid introducing such potential errors.

So, we give up on covariance.  Now what?  We could (taking Don's
suggestion) just disallow another Op for C.  If you want to "refine"
based on the second parameter, you just have to use a different name.
But, that would severely constrain the ability to progam by extension
and in so doing, remove a good piece of why you even bother with OO
construction.

OK, we could try contravariance (ala' Sather).  But now how do we
introduce "refinements" of operations based on their non controlling
parameters?  We've come full circle - use overloading.


It's these sort of issues which (IMO) clearly show that OL is not just
syntactic sugar.  Not by a _long_ way.  It's presence has significant
semantic ramifications for what the object model even is.


> Despite Ada95 being much more clear than C++ in this respect, in complex cases involving
> both overloading and dynamic binding, it is still hardly possible to
> explain in one short sentence (like above) the concept of what's going on.
> 

> Just to change the subject, does anyone know why the designers of
> Ada95 did not choose to include the true multiple-dispatch a la CLOS
> (or point to a reference on this)?  At leat the syntax have been a
> problem; whereas it is in Java/C++/Eiffel.

Maybe Tucker will say something here, but the only thing I have ever
able to determine is that 1) no one knew what the "right" resolution
technique should be when you had multiple distinct types involved
(what's the effective method) and 2) no one really entertained trying
to put in something as complex as the MOP in order to get around 1).

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com