From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 29 Dec 91 06:19:07 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!barmar@ucbvax.Berk eley.EDU (Barry Margolin) Subject: Re: Multiple Inheritance in Ada 9X Message-ID: List-Id: In article <1991Dec29.001511.8007objsys@netcom.COM> objsys@netcom.COM (Object S ystems) writes: Oh boy, a posting from an object system. I guess OO technology has come pretty far! >In article <22010@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes: >//As with other features that are new to the majority of programmers there >//has been quite a debate about multiple inheritance. My impression is that >//most of the debate has been among language laywers and that much have been >//misguided in that it has focussed on obscure points of language law and >//at best weakly supported by experience or notions of programming style. > >Well, since as I've previously posted ::, the scope resolution operator, >isn't a path in C++ (why?) some of the parents (bases) actually aren't >accessible. And CLOS's MI semantic definitions are a real mess. Other than the precise details of the order of classes in the class precedence list, what's a real mess in CLOS? Since the precise order of the CPL is generally unimportant (i.e. most programmers are only concerned that the total order be consistent with the local order of a class and its direct superclasses), this shouldn't be much of a problem. > Since >a scope resolution path seems to solve C++'s problem, it could have just >been C++ nitpicking and confusing semantic rules in CLOS (i.e. a general >lack of understanding *and* early implementations). What "could have just been ..."? >//As noted by Dan Weinreb, C++'s notion of MI is less powerful that that of >//CLOS. That was understood at the time and accepted as something that was >//probably a necessesary price to pay for C++'s static type checking and >//run-time efficiency. > >I must have missed this one, could you please give a pointer or summarize >why CLOS's MI is more powerful? Dan's posting was <1991Dec24.181459.7681@odi.com>; it doesn't go into any details. IMHO, CLOS's MI is more powerful because of the automatic and extensible method combination facility. This permits the very powerful "mixin" style of OO programming to be used very easily. In C++, if multiple base classes contribute to the behavior of a message, the derived class must have a method for the message so that it can explicitly invoke all the base class methods. This means that a change to a class (e.g. to add a method) can require changes to its derived classes (to explicitly invoke it) or to other functions (to use scope resolution to disambiguate the method); this is decidedly non-modular. > After deciphering the semantic mess of >how method selection is performed in CLOS, its not surprising people are >scared of MI. It seems to me they made a semantic rule mountain out of a >little mole hill. As I recall the rules are obscure (linearized) and >had non-intuitive special cases. I think the rules should simply be prefaced by a caveat that the details are rarely significant. The only reason they are specified is so that all implementations will generate the same CPL when the local requirements don't specify a unique one. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar