Re: Multiple Inheritance in Ada 9X

[odi!dlw@uunet.uu.net (Dan Weinreb)]

In article <1991Dec31.110015.17844objsys@netcom.COM> "Bob Hathaway" <objsys@net
com.com> writes:

			     For ??? #2, this looks counter-intuitive.
   Moving common superclasses to the end of the list?  I think this is
   confusing, since the scheme is not consistent (the search would go left
   to right, except...).  

I think Barry explained this already.  The intuition behind this is
"if class A is built on B, then A should come before B" since that's
the way it works for A itself.  There are controversies about the
algorithm for ordering the CPL, but this isn't one of them; it's
clearly right, once you grasp what the CPL is for.

			  And further, does this mean all common
   superclasses are shared?  

Yes; as Barry said, in C++ jargon, CLOS does not support non-virtual
inheritance.  This is one place where C++ is more powerful than CLOS.

   In article <1991Dec30.201051.23038@odi.com> dlw@odi.com writes:
   >//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?

Let me take this opportunity to add that "being more powerful" is not
synonymous with "better, in every way".  Often power comes with
minuses as well as plusses; at the very least, it usually adds some
complexity.  I happen to have found method combination very useful at
times, but I won't deny that one advantage of C++ that makes up for
the lack of method combination is that C++ is simpler.

   Could you please explain how mixins differ from ordinary classes?  They
   look like ordinary classes to me; are you referring to method combinations?

Mixins are indeed ordinary classes, but they are called "mixins" when
you intend to use them in certain ways.  A mixin is a class whose
author intended that the class get mixed into other classes in order
to add some functionality.  I can write a mixin M, and the you can
write class A and simply mix in M, and your friend can write class B
and mix in M.  M does not "know about" A or B in any way.  And the
important thing is that M can tack on additional behavior
automatically because of automatic method combination.  So the concept
of "mixin" is really only an interesting concept because method
combination exists.

   Also, while I've got a real CLOS programmer here, I've wondered about
   multi-methods and no class structuring.  Does this get in the way?

Actually, I've never programmed with multi-methods.  My own experience
is with one of the predecessors of CLOS (namely, Flavors) that didn't
support multi-methods.  So I can't answser from experience.

   Since dynamic functions or dummy receivers superset multi-methods but
   I don't think multi-methods superset OO-style invocations, have you ever
   worried some operation on a class would get pulled away by some other
   multi-method which matched closer on some later parameter?  

That's a good question and I don't know to what extent this really
happens.  I do know that with static overload resolution, which is
sort of analogous to this, it is indeed possible to get confused when
things get complicated.

							       Has the
   lack of encapsulation/protection gotten in the way of reliable,
   large-scale systems building?  Inquiring minds want to know...

Ah, well, that's a bigger question.  I do think that Lisp would be
better off with a better encapsulation/protection paradigm.  What it
has right now is "packages".  I am one of the people who invented
this, and I am not happy with it.  If I were going to do a major
overhaul, this is one of the main things I'd want to work on.  You
might want to see whether the Scheme developers have come up with
something good in this area; they're really the vanguard of Lisp
development as far as I know.