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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e9ec140e4d84359f X-Google-Attributes: gid103376,public From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: No multiple dispatch in Ada95? Date: 1995/04/06 Message-ID: X-Deja-AN: 100939407 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: spock.camb.inmet.com references: <3lu8tp$eep@disunms.epfl.ch> organization: Intermetrics, Inc. newsgroups: comp.lang.ada Date: 1995-04-06T00:00:00+00:00 List-Id: 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.