Re: Eiffel and Java + Ada dispatching

[jsa@alexandria (Jon S Anthony)]

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

> >1) the dot notation makes the operation _look_ like a field of the object but
> >   in general this is _not_ true (some OOLs do have per object methods but
> >   not the usual ones like Eiffel, C++, Sather, etc...)

> What do you mean? Conceptually it *is* (can be though of as) a
> field of the object (if I gather well what you mean by field). That
> it uses to not be at runtime is a compiler optimization. Or do you
> mean something else?

In languages like Eiffel, Sather, C++, etc. it is not a compiler
optimization.  That the operation is not part of the object is part of
the semantics of the language.  You cannot change this operation on a
per object basis.  Now, you can say that Joe Programmer can think this
way (that the operation is part of the object), but that just means he
doesn't understand the language.


> >2) the dot is asymmetrical and makes many cummutative operations look
> >   lopsided.  For example, Union(set_a, set_b) = Union(set_b, set_a), and
> >   the notation should reflect this (infix would be even nicer here).  But
> >   in "dot land" you have set_a.Union(set_b) which looks like set_a _has_
> >   the operation and is "special" somehow.
> 
>
> The problem is much more profound, because if you have single
> dispatch only, it *is* "special" somehow, whatever the syntax you
> use to write it.

No it is not.  The object does not contain the operation.  The
language semantics do not allow this interpretation.  You can pretend
that it does, but it doesn't.  You are not actually sending a message
to set_a.  Now, if we were talking about a _delegation_ based
language, then you would definitely have a point.

There is nothing special about set_a from set_b.  They are both of the
same class.  Both have the exact same operation Union.  Hmmm, unless
you are thinking of the case where set_b and set_a are _not_ in the
same class.  While this can happen in Eiffel, it can't happen in Ada,
so maybe this is where the problem is.


> For binary operations, it seems that there is no other way that
> double-dispatch (built in as in CLOS, or emulated as everywhere
> else).  Check e.g. the recent article "On Binary Methods" by Bruce,
> Cardelli et al. in Theory and Practice of Object System. Static

Are you saying that only multi-dispatch semantics allow "proper"
binary operations?  If so, why???  Also, note that in CLOS with the
two operands of the same type, the effective method will simply be
what Ada does anyway - select their single operation and perform it.
It's just that in CLOS you aren't restricted to _only_ this outcome.


> binding of one of the paramater poses problem, and in this respect
> Ada95 does not bring anything new (and in this respect is no better
> than C++/Java/Eiffel/Sather etc.).

I'm not sure I understand you here.  Ada does not statically bind one
parameter and not the other.  That is illegal.  Either all the
controlling parameters are dynamic or they are all static.  In either
case they have to be of the same type.


> Prove me wrong, please, and win a paper in TPOS.  But please, do not
> quote me outside of the context this time.

I'm not sure what the question or assertion even _is_, much less
whether you are wrong or not.


> of Current and Other ...  but unless you redispatch on the dynamic
> type of 'other', it does not solve the problem.

What problem?


> >3) the function notation allows Ada to dispatch based on the _result_ of
> >   parameter which is a function call.  Or has the function dispatch to
> >   the right thing based on the other parameters.  Bob Duff gave a couple
> 
> I have trouble understanding these sentences. Could you please reformulate
> in English or even American English?

Yes, on reading them, the sentences have some typos.  Oh well.


> >   Union(My_Set, Singleton(X)), where Singleton's dispatching is the
> >   controlling _result_ and _not_ the argument (with X being an integer
> >   or something).  Here, Singleton would dispatch to the proper version
> >   based on the tag of My_Set.
> >
> >   (Singleton(X) + Singleton(Y)) * My_Set, where "+" is union and "*" is
> >   intersection.  Here the tag of My_Set would control the dispatch of
> >   the Singleton operations.
> 
> Well, I still cannot see what it buys you beyond being able to
> choose at *compile time* (i.e. statically) the position of the
> parameter that receives the dispatch

It is a kind of (very) simple multi-dispatch.  Sort of.  The function
call will dispatch to the proper operation _based on_ the dynamic tags
of the other parameters and then the "outer" operation (the one with
the function as one of its parameters) will dispatch.

It is indeed, very constrained and not something to get wildly excited
about, but it is neat and useful.


> (big deal, IMHO) ? Or do you mean something else?  In that case,
> please give us a more complete example. Or would a real Ada95 expert
> tell us? (Yvon, are you still there?)

My my, we are getting nasty now, aren't we?  The examples I gave above
(as I indicated) came from Bob Duff - co-designer of Ada95.  I'm not
sure why you don't understand the examples - they are pretty straight
forward.


> >Well, sort of...  Seems like pretty extraneous futzing to accomplish
> >such a simple and ordinary thing.
> 
> Dealing with binary methods whose both arguments can be instances
> of subtypes of the declared types is *not* a "simple and ordinary
> thing". Again, if you have such a simple solution, tell us! I'll
> praise you then.

Well, now we see the problem.  As has been stated several times, the
subtypes must be _the same_ and are checked dynamically (in a
dispatching case) and statically (in a compile time case) for this.
You are thinking (as in Eiffel) of _dispatching_ operations which can
take _variants_ of the types.  In Ada, only operations of class-wide
types can take such variants at runtime and they are not dispatching -
completely statically bound at compile time.  They can just take any
instance of any type covered by their class-wide parameters.

Here's a case of someone who only sees one way of looking at things,
doesn't understand the other model, and then says it can't be done
because he is thinking solely in terms of the model where it is "*not*
a simple and ordinary thing".  Shrug.


> >Actually, if you stated this as "for my areas, symmetric ops are
> >relatively few", I could buy it.  But in general symmetric operations
> >are all over the place.
> 
> How can you say that?

Easy.

> I agree that they are quite commonplace in
> math-related software (linear algebra, sets etc.), and could
> sometimes appear in other pieces,

Exactly.

> but not to the point of being ubiquitous.

No one said they were.

> But that's not the point. Well, what is your point anyway?

Just that - depends on the area.  What's your point?  I mean, you sort
of got my point.


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