Re: Multiple Inheritance in Ada 9X

[netcomsv!objsys@decwrl.dec.com (Bob Hathaway)]

[This turned out fairly long.  I think any CLOS responses should be directed
 to comp.object and perhaps comp.lang.clos]

In article <klqq6rINNn1e@early-bird.think.com> barmar@think.com (Barry Margolin
) writes:
--Oh boy, a posting from an object system.  I guess OO technology has come
--pretty far!

Actually, I forgot to fill in my name above (it defaults), so I feel
its important to point out that this programs opinions are its own
and not necessarily the opinion of its writer.

-->>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.

Well, thanks for answering.  I haven't grabbed a PD CLOS compiler yet,
so I had to go by the articles instead of writing test programs, giving
their definitions a try.

"The Common Lisp OO Programming Language Standard", 4.3.1 Inheritance
Conflicts starts by stating each superclass is listed once in its
class precedence list(hmmm).  It then describes how CLOS prioritizes
the parents in order from left to right (interesting, what if I don't
want to define an ordering?  Can I access the lower priority class
slots at all?  Can I query the class if necessary and then specify
the path?).

And then there's point three:  When direct superclasses are independent
except for a common ancestor class, a similar property holds [left to
right priority of parents], provided that the common ancestor appears
only as the last element of a direct superclass list., never in the
middle of one [???].  The class precedence list consists of the noncommon
superclasses of the first direct superclass, followed by the noncommon
superclasses of the second direct superclass, and finally the common
ancestor and its superclasses [???].  

I figured out the first ??? a while ago, but maybe a real CLOS programmer
can give a good example.  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...).  And further, does this mean all common
superclasses are shared?  If so, this seems like dangerous, large
granularity (class-level) structural sharing to me.  I can define
two independent classes each inheriting from say, a list class.
Each of these two classes depends on its own list parent.  With
shared superclasses, if I define a new class which inherits from both,
both parents integrity is compromised!  It looks to me that if I
use MI in CLOS, I must check for such duplications and may be
precluded from combining certain classes as parents (obviously
not so when shared and non-shared superclasses are available, as in C++).
Do I understand the CLOS definitions correctly?  Can I get non-shared
superclasses in CLOS?

-->                                                                  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 ..."?

The individuals complaining that single inheritance is preferred to 
multiple inheritance, I think they lacked understanding *and* only
saw incipient work (I was also joking to make a point).

There is also the Object Specialization camp, which provides the
equivalent of MI thru object hierarchies but I still prefer MI
since it is far more convenient than constructing object hierarchies
linearly and because MI fits in with hybrid prototype/class OO systems
well.  I feel these authors fell into the "very early" category and
should consider removing their tree hierarchy constraint because of
simplicity of use.  Any other opinions?


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?

[Covering method combinations]

I agree, method combinations are a nice facility.  I assumed Dr. Stroustrup
was referring to CLOS's dynamic nature, which I think can coexist with
a static nature just fine (what I'm doing).  Can CLOS take advantage 
of static facilities?  If not, can meta-level access provide this for
efficiency and compile-time checking?  How about CLOS and prototyping,
is it provided or can meta-level access help?

--                                                            The main
--thing I think matters the most is that "mixin" classes can be
--established in a library, and then users of the library can draw upon
--them and use them together in whatever pattern in appropriate.  This
--is harder or impossible to do in C++ and most non-CLOS-like approaches
--that I am aware of.

Could you please explain how mixins differ from ordinary classes?  They
look like ordinary classes to me; are you referring to method combinations?
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?
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?  Has the
lack of encapsulation/protection gotten in the way of reliable,
large-scale systems building?  Inquiring minds want to know...

--This is exactly what I mean about language theorists.  In fact, it's
--not a "semantic mess".  It's well defined, and in real-life
--circumstances it's simple and natural.  Many programmers who I worked
--with, including me, used this stuff (actually its predecessor,
--Flavors; CLOS is actually an improvement) every day, for years,
--producing many, many thousands of lines of code, with no problem.

Well, I admit I haven't used the language yet, but I'm genuinely interested
in the answers to the previous questions.  I was speaking from a software
engineering perspective, not a theoretical one.

--           Maybe you're the kind of person who never uses a hammer
--under any circumstances because it is possible for the hammer head to
--fly off and cause damage, and so you're waiting for the Perfect
--Hammer.  But there are plenty of CLOS programmers who find it to
--be a very useful tool, and they'll happily use it until a better
--one comes along.

That is my intention (providing a better one that is:-)

bob
objsys@netcom.com