* No multiple dispatch in Ada95? @ 1995-04-05 0:00 Fernando Mato Mira 1995-04-06 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Fernando Mato Mira @ 1995-04-05 0:00 UTC (permalink / raw) Hello, I checked the reference manual. There's no multiple dispatching in Ada95? I see no reason why a left-to-right disambiguating rule was not good enough. You only add the extra dispatching complexity when the methods defined require it. And it should be faster than simulating it by a `double dispatch'. What's worse, time is already wasted checking for a Constraint_Error. I have to leave CLOS for a year. I would have exchanged multiple inheritance for multiple dispatch. Now it's not clear that the effort or risk of choosing Ada95 instead of C++ (yuck!) is worth it. [Yes, I know C++ is risky _by design_] Really big goof, and it's a pity given that Ada got the `message send' syntax right.. PS: And why not reaping the benefits of both single inheritance and contract-based design by restricting inheritance to only one parent with structure plus an arbitrary number of abstract parents with null records? -- F.D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab matomira@epfl.ch EPFL FAX: +41 (21) 693-5328 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: No multiple dispatch in Ada95? 1995-04-05 0:00 No multiple dispatch in Ada95? Fernando Mato Mira @ 1995-04-06 0:00 ` Robert Dewar 1995-04-07 0:00 ` Fernando D. Mato Mira 1995-04-06 0:00 ` Mark A Biggar 1995-04-06 0:00 ` Tucker Taft 2 siblings, 1 reply; 8+ messages in thread From: Robert Dewar @ 1995-04-06 0:00 UTC (permalink / raw) Well that's amusing! someone says it is a "really big goof" to leave out multiple dispatching. Well I guess this is to be expected from a CLOS refugee :-) But just for the record, this was not some accidental oversight, it was certainly discussed, and here was NO (as in ZERO) support for even considering this additional complexification. For those who don't know CLOS, if you are bored with the excessive simplicity of the Ada OO model, this should be a good antidote :-) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: No multiple dispatch in Ada95? 1995-04-06 0:00 ` Robert Dewar @ 1995-04-07 0:00 ` Fernando D. Mato Mira 0 siblings, 0 replies; 8+ messages in thread From: Fernando D. Mato Mira @ 1995-04-07 0:00 UTC (permalink / raw) In article <dewar.797220733@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: > Well that's amusing! someone says it is a "really big goof" to leave out > multiple dispatching. Well I guess this is to be expected from a CLOS > refugee :-) Smalltalk-raised, custom `object-oriented C' hacker, Eiffel 2.3-molded, CLOS/MOP refugee and C++ victim! :-) -- F.D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab matomira@epfl.ch EPFL FAX: +41 (21) 693-5328 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: No multiple dispatch in Ada95? 1995-04-05 0:00 No multiple dispatch in Ada95? Fernando Mato Mira 1995-04-06 0:00 ` Robert Dewar @ 1995-04-06 0:00 ` Mark A Biggar 1995-04-07 0:00 ` Fernando Mato Mira 1995-04-06 0:00 ` Tucker Taft 2 siblings, 1 reply; 8+ messages in thread From: Mark A Biggar @ 1995-04-06 0:00 UTC (permalink / raw) In article <3lu8tp$eep@disunms.epfl.ch> matomira@di.epfl.ch (Fernando Mato Mira) writes: > I checked the reference manual. There's no multiple dispatching >in Ada95? > I see no reason why a left-to-right disambiguating rule was not good enough. > You only add the extra dispatching complexity when the methods defined >require it. And it should be faster than simulating it by >a `double dispatch'. What's worse, time is already wasted checking >for a Constraint_Error. The major reason for leaving out multiple dispatch is that given the limitations that would have to be put on it it would be practically useless. Note that the only dispatching operations in Ada95 are the primitive operation of the tagged type and those can only be defined in the same package spec as the tagged type declaration itself and even then only until you do something to freeze the type (like derive another type from it). So once you derive a new tagged type from an old one you can now longer define dispatching operaton on the parent type. This means that if, for example, I had tagged types A and B with new type C derived from A and D derived from B and the multiple dispatching operator F(A, B), then only new dispatching version I can define is F(C, D). If I define F(A, D) it wouldn't be dispatching on A and likewise F(C, B) wouldn't be dispatching on B. And even then all that would have to be defined in the same package spec. Basically adding multiple dispatch to the language would require redisigning the whole tagged type system. >PS: And why not reaping the benefits of both single inheritance > and contract-based design by restricting inheritance to > only one parent with structure plus an arbitrary number of abstract > parents with null records? That solves the duplicate data member problem but doesn't solve the duplicate operation problem. -- Mark Biggar mab@wdl.loral.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: No multiple dispatch in Ada95? 1995-04-06 0:00 ` Mark A Biggar @ 1995-04-07 0:00 ` Fernando Mato Mira 1995-04-07 0:00 ` Norman H. Cohen 0 siblings, 1 reply; 8+ messages in thread From: Fernando Mato Mira @ 1995-04-07 0:00 UTC (permalink / raw) In article <1995Apr6.163750.11289@wdl.loral.com>, mab@dst17.wdl.loral.com (Mark A Biggar) writes: > useless. Note that the only dispatching operations in Ada95 are > the primitive operation of the tagged type and those can only be > defined in the same package spec as the tagged type declaration itself > and even then only until you do something to freeze the type (like > derive another type from it). I was also dissapointed by this. I found that the inability of defining a new virtual for a set of classes without access to source code is a slap in the face to reuse (of couse, such new operations should live in a different package, to avoid problems when you get a new release of that library). > That solves the duplicate data member problem but doesn't solve the duplicate > operation problem. I know. I was not looking at name clash problems. Eiffel does just fine, and its solutions to the latter are less of an efficiency concern as the support for multiple inheritance of data members. BTW, hierarchical packages are cool. I argued about this some time ago in comp.lang.lisp, and I was happy to see them in Ada95 Given the quest of both lispers and ada fans for _The_Right_Thing_ (with a different set of values), the support for multiple dispatching in both would have made a nice parallel and a good delivery option when MOP or dynamic features were not required. And given that the DoD puts money in Lisp projects, too, that might have looked interesting to them.. Oh, well..*sigh* -- F.D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab matomira@epfl.ch EPFL FAX: +41 (21) 693-5328 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: No multiple dispatch in Ada95? 1995-04-07 0:00 ` Fernando Mato Mira @ 1995-04-07 0:00 ` Norman H. Cohen 0 siblings, 0 replies; 8+ messages in thread From: Norman H. Cohen @ 1995-04-07 0:00 UTC (permalink / raw) In article <3m3c72$5ms@disunms.epfl.ch>, matomira@di.epfl.ch (Fernando Mato Mira) writes: |> I was also dissapointed by this. I found that the inability of |> defining a new virtual for a set of classes without access to |> source code is a slap in the face to reuse (of couse, such new operations |> should live in a different package, to avoid problems when you get |> a new release of that library). I don't understand the problem. You can derive from a tagged type in a child of the package in which that type is declared, inheriting the operations of the original and adding others. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: No multiple dispatch in Ada95? 1995-04-05 0:00 No multiple dispatch in Ada95? Fernando Mato Mira 1995-04-06 0:00 ` Robert Dewar 1995-04-06 0:00 ` Mark A Biggar @ 1995-04-06 0:00 ` Tucker Taft 1995-04-07 0:00 ` Robert Dewar 2 siblings, 1 reply; 8+ messages in thread From: Tucker Taft @ 1995-04-06 0:00 UTC (permalink / raw) Fernando Mato Mira (matomira@di.epfl.ch) wrote: : I checked the reference manual. There's no multiple dispatching : in Ada95? : I see no reason why a left-to-right disambiguating rule was not good enough. : You only add the extra dispatching complexity when the methods defined : require it. And it should be faster than simulating it by : a `double dispatch'. What's worse, time is already wasted checking : for a Constraint_Error. Multiple dispatching would require a relatively big shift away from type-specific "primitive" operations (also called "dispatching operations" when the type is tagged), to the "free-floating" methods of CLOS. In CLOS, a "generic function" has an associated set of methods that implement it, and at run-time a selection among these methods is made based on the actual parameters. In single-dispatching OOPLs (most others), each type has a set of operations and a set of ancestors, and these are searched (at compile-time in Ada 95, C++, Eiffel, Simula, Object Pascal, Modula-3, Oberon, ...; at run-time in SmallTalk, Objective-C, ...). Visibility control in CLOS is oriented around packages, which have no particular connection with where types or methods are declared. Visibility control in most other OOPLs is oriented around a module (Ada 95, Object Pascal, Modula-3, Oberon, ...) or class construct (C++, Eiffel, SmallTalk, ...), with types and the associated operations encapsulated by the visibility-controlling construct. Hence, adopting multiple dispatching as in CLOS would probably require abandoning the Ada principle that packages provide an encapsulation of types and their associated operations, as well as being the basis for visibility control. In addition, to be efficient, multiple dispatching typically involves some kind of hash-based lookup at run-time. Our philosophy for Ada 95 was that such operations are better implemented by the programmer, in an appropriate application-specific way. It is highly unlikely that the compiler and run-time support will ever be able to match the programmer's knowledge about a particular problem needing multiple dispatch, so it is better for the programmer to define and implement such an abstraction than to bury the complexity and potential unpredictable space and time requirements in the compiler and run-time support. Of course with CLOS, you have your Meta-Object Protocol, but that is a *very* big bite (byte?) to swallow... : ... Ada got the `message send' : syntax right.. That's nice to hear ... : PS: And why not reaping the benefits of both single inheritance : and contract-based design by restricting inheritance to : only one parent with structure plus an arbitrary number of abstract : parents with null records? We considered this. However, even a little bit of linguistic multiple inheritance introduces complexity requiring name-collision management, multiple virtual function tables, etc. It is interesting to note that the conventional wisdom in C++ seems to be swinging over to emphasizing the value and importance of templates relative to inheritance (e.g., the new "Standard Template Library" for C++ makes only minimal use of inheritance, but makes heavy use of templates). In Ada, generics are even more useful, because you can identify explicitly the set of operations a formal type parameter is supposed to have. Instantiating a generic is the most flexible kind of "interface" inheritance, particularly in Ada, where the operations on a type can be effectively renamed as part of the instantiation. Overall, our belief is that robust support for generics, plus the "multiple namespace inheritance" already provided by Ada's "with" and "use" clauses, obviates much of the need for "linguistic" support for multiple inheritance. Whatever is left can be readily and flexibly handled by the sophisticated type composition facilities provided by Ada 95, including the concept of an "access discriminant" which allows one object to refer to another object, including possibly its enclosing object. : F.D. Mato Mira http://ligwww.epfl.ch/matomira.html : Computer Graphics Lab matomira@epfl.ch : EPFL FAX: +41 (21) 693-5328 -Tucker Taft stt@inmet.com Intermetrics, Inc. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: No multiple dispatch in Ada95? 1995-04-06 0:00 ` Tucker Taft @ 1995-04-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 8+ messages in thread From: Robert Dewar @ 1995-04-07 0:00 UTC (permalink / raw) Just so I am not misunderstood, when I "complained" about the complexit of CLOS, I was specifically referring to the Meta-object protocol, which is quite a challenge even for those with a taste for complex things! It is quite true that a simple level of multiple dispatching could have been implemented. We actually looked into this in considerable detail in the Griffin project at NYU, but our final conclusions were very close to those posted by Tuck in reference to adding MD to Ada. I think this is one place where Tuck probably made the cut correctly. After all it is interesting that Tuck (not known for his fear in the face of complexity :-) never seriously suggested adding this feature, because he felt from the start that it did not fit well without major conceptual and language changes. Oh-oh, I just realized that the last para could be read to mean I imply that Tuck didn't make the right cut anywhere else. I certainly didn't mean that. There are perhaps just 1 or 2 places where I would have liked the cut a little differently (I still miss in out parameters on functions), but only 1 or 2 :-) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1995-04-07 0:00 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1995-04-05 0:00 No multiple dispatch in Ada95? Fernando Mato Mira 1995-04-06 0:00 ` Robert Dewar 1995-04-07 0:00 ` Fernando D. Mato Mira 1995-04-06 0:00 ` Mark A Biggar 1995-04-07 0:00 ` Fernando Mato Mira 1995-04-07 0:00 ` Norman H. Cohen 1995-04-06 0:00 ` Tucker Taft 1995-04-07 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox