From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java + Ada dispatching Date: 1996/11/12 Message-ID: #1/1 X-Deja-AN: 195887438 sender: news@organon.com (news) references: 03: 26:59 GMT organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-12T00:00:00+00:00 List-Id: 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