Re: Multiple Inheritance in Ada 9X

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!barmar@ucbvax.Berk eley.EDU (Barry Margolin)]

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