Re: Eiffel and Java + Ada dispatching

[jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel)]

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

>Actually, while it is not multiple dispatching (multi-methods), the
>syntax does indeed allow several little niceties that the dot notation
>flubs.  It is this stuff that is the "justification" - not any so called
>"hybrid" aspects.
>
>
>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?


>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.
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 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.). Prove me wrong, please, and win a paper in TPOS.
But please, do not quote me outside of the context this time.

BTW you could write: set_c := set_a + set_b in Eiffel, with the declaration
infix "+" (other: SET): SET is
-- returns union of Current and Other
...

but unless you redispatch on the dynamic type of 'other', it does not solve
the 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?

>   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 (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?)


>> it is special. The downside is that symmetric operations do not
>> appear as such. Well, not really, because you can always regain it
>> by inventing another class for performing symmetric operations:

>> eg. class SET_OPS
>>       ...
>>       union (a, b: SET): SET is ...
>>       intersection (a, b: SET): SET is ...
>>       ...
>>     end

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

>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? I agree that they are quite commonplace in math-related software
(linear algebra, sets etc.), and could sometimes appear in other pieces, but not to the
point of being ubiquitous. But that's not the point. Well, what is your point anyway?

---
Jean-Marc Jezequel               | Tel : +81 (3) 3812-2111 ext. 4116
IRISA/CNRS, currently visiting:  | Fax : +81 (3) 5689-4365
Dept. of Information Science     | e-mail : jezequel@irisa.fr  or
Faculty of Science               | e-mail : jezequel@is.s.u-tokyo.ac.jp
The University of Tokyo          | http://www.irisa.fr/pampa/PROF/jmj.html   
Hongo Bunkyo-Ku, Tokyo 113, JAPAN