Re: Multiple Inheritance in Ada 9X

Re: Multiple Inheritance in Ada 9X

[icd.ab.com!iccgcc.decnet.ab.com!klimas]

In article <1991Dec23.182008.3383@linus.mitre.org>, gary@maestro.mitre.org (Gar
y Bisaga) writes:
> In article <1991Dec20.094627.6517@iccgcc.decnet.ab.com>, klimas@iccgcc.decnet
.ab.com writes:
> |> 	If you're going to implement MI, please study what has been done alread
y
> |> 	very closely because there seems to be a uniform story comming back
> |> 	from different sources and technologies that the current
> |> 	implementations of MI create more troubles than benefits. 
> Besides this paper (reference deleted in article citation), what other
> study results have you seen to support this conclusion?  I am honestly
> interested in such results, as I have used MI to (I think anyway) good
> effect.
	There have been a number of OOPSLA workshops where these issues
	have been discussed.  One more recent paper on the subject with
	a number of other references in it that comes to mind is 
	"The Point of View notion for Multiple Inheritance" by Carre and
	Geib in the OOPSLA/ECOOP 90 proceedings.

	The OOPSLA 91 experience reports had several presnters also discussing
	issues with MI.

	Lipmann's excellent C++ book also has some very good guidelines and
	caveats about MI.

	To reitterate my original statement, MI can lead to very elegant
	solutions for many simple problems, but when extended to more complex
	situations the current scheme's appear to run into problems.
	My point is not to dispute the utility of MI, just to alert the
	original poster that there is not a clear agreement in the OOP
	community that the current MI schemes are good ideas.

Re: Multiple Inheritance in Ada 9X

[Bjarne Stroustrup]

There is not to my knowledge any evidence that multiple inheritance
(as implemented in C++ or elsewhere) is particularly dangerous or where
used for real projects has caused any harm.

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.

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. 

Somebody used the phrase ``bolted on'' about C++'s multiple inheritance
facility. I consider that a typical misunderstanding/misrepresentation.
FYI: Multiple inheritance was first considered very early on in the
development of C++ (about 1982) but the actual introduction was delayed
until 1986 when I felt I had enough understanding, experience,and time
to tackle the issue.

MI in C++ and elsewhere isn't perfect and it isn't a panacea, but it works
and it makes some styles of programming noticeably more convenient and
less obscure. Naturally, it can also be overused and misused, but basically
it works.

Re: Multiple Inheritance in Ada 9X

[Object Systems]

In article <22010@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
//There is not to my knowledge any evidence that multiple inheritance
//(as implemented in C++ or elsewhere) is particularly dangerous or where
//used for real projects has caused any harm.

There are articles (not with me at the moment) documenting the mess
(in real projects) made of single inheritance to achieve multiple
inheritance, including dumping the contents of a base class into a
derived class because only one parent was allowed.  This is code
duplication, so I believe a lack of MI is actually harmful.

Also, I wouldn't seriously consider an OO language usable if it didn't
support MI.  Ada's generics, exception handling, and tasking are getting
old but at least they are there.  But without full OO support, including MI, 
the suitability of Ada becomes less clear.  Also (while digressing), isn't
tasking now obsolete with active objects, multiple-threads per method,
asynchronous exception handling/message passing to active objects, etc.
ad infinitum as standard extensions?  The semantics all fit in perfectly
with classes and the syntax comes practically for free (no separate tasking
constructs) so I don't see any need for the less structured tasking for
the old ada-style dynamic OO programming anymore.

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

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

//Somebody used the phrase ``bolted on'' about C++'s multiple inheritance
//facility. I consider that a typical misunderstanding/misrepresentation.
//FYI: Multiple inheritance was first considered very early on in the
//development of C++ (about 1982) but the actual introduction was delayed
//until 1986 when I felt I had enough understanding, experience,and time
//to tackle the issue.

I agree, for dynamic MI there seems to be confusion to: a good compiler
writer once told me you'd need to keep track of the complete object for
dynamically typed MI and now I believe this is simply not true, MI just
breaks down to the simple SI case, dynamically or not (notice no CLOS 
definitional confusion here, it really is that simple).  The only
special case is for shared base classes, which is trivially handled
and defined.  And maybe add repeated bases (same class) with a means
for specifying each, etc.  (A good proposal should deal with all of
these issues and more)

//MI in C++ and elsewhere isn't perfect and it isn't a panacea, but it works
//and it makes some styles of programming noticeably more convenient and
//less obscure. Naturally, it can also be overused and misused, but basically
//it works.

I think a major contribution of MI is to design/modeling, where without it
you are less able to model your problem domain, abstract or not.  Also,
the new research area in MI is dynamic inheritance: modeling changing
entities such as a boy into a man, an account into an overdrawn account
which cannot make withdrawls, adding parents dynamically, switching roles,
etc.  Another issue is the schema evolution problem, which is not much
different from and may be solvable by dynamic inheritance.

While simple programming does not require such a dynamic system,
advanced ones do and if Ada-9x is to keep Ada abreast of modern
techniques for at least another 10 years this should be a priority
area in any proposal.  A friend (B.W.) recommended an article on this
subject entitled "Object Specialization" (sorry not with me) which
appeared in the ACM Transactions on Information Systems about two
years ago.  He pointed out it is being seriously considered as the
framework for inheritance in Ada-9x.  It provides at least one early
attempt at combining both dynamic and static inheritance into a single,
uniform, one-layered, and usable facility.

bob
objsys@netcom.com

Re: Multiple Inheritance in Ada 9X

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!barmar]

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

Re: Multiple Inheritance in Ada 9X

[bu.edu!inmet!inmet!stt]

In article <829@ajpo.sei.cmu.edu>, 
goodsenj@ajpo.sei.cmu.edu (John Goodsen) writes:

> I'm about to develop a comprehensive paper discussing the
> necessity for multiple inheritance to be included into Ada 9X,
> under the request of the mapping/revision team.
> 2 questions:
> 
> 1) Who's done this before (both created the paper AND sent it to the mapping/
>    revision team -- surely I'm not the first).  What were your results (ie.
>    is it a waste of time like so many have told me in the Ada community, or
>    is this a worthwhile effort) ?

We welcome both comments and papers related to the Ada 9X effort.
Unfortunately, we are not able to respond individually to every comment,
though we do read them and try to incorporate what we learn into the
Ada 9X "mapping" proposals.

> 2) Assuming it's not a waste of my efforts, please send me any
>    pertinent information which you feel will need to be included in
>    this paper (personal examples, journal/textbook references, etc.).

We actually posted a request for "real" examples of Multiple Inheritance
on "comp.lang.c++" about a year ago.  We received several responses, but
no "real" examples.  In Eiffel, Multiple Inheritance is used for
essentially all external references between classes.  Ada already has
the "with" clause for establishing external references, and in that
very limited sense already supports multiple inheritance.

What we are interested in is whether it is important to be able
to combine two types to form a third which is an "extension" of both.
By this we mean that the new type incorporates the "state" of the two
parent types, and can be passed to operations which accept either of
the parents.  Of course, where MI gets nasty is when the same ancestor
type is inherited through two different paths.  Complexity arises in
deciding whether to replicate the ancestor state or share part or
all of of it in the descendant type.  Furthermore, if the same
method is defined along both paths, there must be some resolution
rule to select the appropriate method to be inherited in the new
type.  

Eiffel uses renaming to control
replication versus sharing.  C++ uses the concept of "virtual" base
classes to accomplish sharing.  CLOS uses slot names to determine
sharing, plus deterministic ordering rules to select methods.

In any case, it is clear that multiple inheritance can add complexity
to both the implementation (even when not used) and to the user
view of the language.  Multiple inheritance can also be partially
supported through the use of other composition mechanisms (e.g.,
by making one parent a component rather than an ancestor, or by
using the "with" clause approach, or by using generics).
We are interested in examples which show how multiple inheritance
leads to a simpler solution to a realistic problem than that provided by
the other available composition mechanisms.  Such examples
should then help in making the right trade off between expressibility
and language and implementation complexity.

In the most recent public release of the Ada 9X Mapping Specification
(December 1991, Version 4.0 -- available soon on ajpo.sei.cmu.edu),
we do provide building blocks for multiple inheritance, 
but we do not provide direct support.  
It would be particularly useful if examples could be worked
out using the proposed building blocks (see section 3.8.2 of
the Mapping Specification for a description of the building blocks).

For the adventurous, here is a trivial example of multiple
inheritance using the proposed Ada 9X mechanisms:

   -- Root types for Smalltalk-inspired MVC Graphic User Interface
   type Model is tagged limited private;
   type View is tagged limited private;
   type Controller is tagged limited private;

   procedure Add_View(M : in out Model; V : access View'CLASS);
     -- Add a view to a model
   procedure Update_View(V : in out View; M : Model'CLASS);
     -- Update a view when the model changes

   type Window;  -- incomplete type

   type View_Mixin(Win : access Window'CLASS) is 
     new View with limited private;  -- View to be "mixed in" to a window

   type Controller_Mixin(Win : access Window'CLASS) is 
     new Controller with limited private;  -- Controller to be "mixed in"

   type Window is new Basic_Window with record
     -- Window with two mixins
     V : View_Mixin(Window'ACCESS);  -- Discrim points to enclosing window
     C : Controller_Mixin(Window'ACCESS);  -- Discrim points to enclosing win
   end record;

If we have an object "W : Window" then we can pass W.V
to operations on Views, and W.C to operations on Controllers.
These operations can reference the enclosing window object through
the "access discriminant" which has been default initialized to point at W
using the ACCESS attribute.

The forthcoming revised Ada 9X Mapping Rationale (due by end of February)
will contain more such examples, hopefully.

> Thanks in advance -
> 
> 
> John Goodsen
> Products Manager
> SETT, Inc.
> goodsenj@ajpo.sei.cmu.edu

S. Tucker Taft
Ada 9X Mapping/Revision Team    (ada9x-mrt@inmet.inmet.com)
Intermetrics, Inc.
733 Concord Avenue
Cambridge, MA  02138

Re: Multiple Inheritance in Ada 9X

[Dan Weinreb]

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.

Yes, I think you've stated it very well.

There have indeed been debates, at OOPSLA and in other forums, about
various designs for multiple inheritance features.  I think most
reasonable people agree that none of the present designs seems to be
perfect.  None is the absolute undisputed last word about the Right
Way to do MI.  In most of them, it is possible to construct complex
scenarios in which the behavior of the language, although
well-defined, can become difficult to understand and possibly
surprising.

But to say that this means that MI should be shunned or banned is to
let the perfect become the enemy of the good.  After all, I think
there are flaws in many areas of many languages, but that doesn't mean
we should all go back to assembly language.  Present MI features are
very useful for many everyday practical purposes despite their flaws,
and this has been shown by many years of experience.  The problems are
of much more interest to language designers and theoreticians (who are
strongly represented at OOPSLA) than to practical programmers.  The
language designers and theoreticians should, by all means, spend time
analyzing the flaws in all the existing languages, and attempting to
come up with improved approaches.  Meanwhile, though, the practical
programmers need not shun existing MI languages.  Instead, they should
understand how to use them as well as they can be used, and I think
they'll find that the effort is worthwhile.

Re: Multiple Inheritance in Ada 9X

[Dan Weinreb]

In article <1991Dec29.001511.8007objsys@netcom.COM> objsys@netcom.COM (Object S
ystems) writes:

   I must have missed this one, could you please give a pointer or summarize
   why CLOS's MI is more powerful?  

I think Barry summarized the important points pretty well.  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.

				    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.

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.

If you are a language theorist, and you work hard at it, you can
construct cases in which CLOS's behavior regarding the ordering of the
CPL is sometimes counterintuitive.  This kind of thing is rare in
practice.  It's important to theoreticians, but for real programmers
it makes no difference.  The hue and cry that has been raised about
this is completely unjustified from the point of view of getting the
job done.  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.

Re: Multiple Inheritance in Ada 9X

[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

Re: Multiple Inheritance in Ada 9X

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

Re: Multiple Inheritance in Ada 9X

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!darwin.sura.net!Siriu]

In article <1991Dec20.094627.6517@iccgcc.decnet.ab.com>, klimas@iccgcc.decnet.a
b.com writes:
> If you're going to implement MI, please study what has been done already
> very closely because there seems to be a uniform story comming back
> from different sources and technologies that the current
> implementations of MI create more troubles than benefits. 

Multiple inheritence is a method of reflecting in software, properties of a
real-world entity to be modelled, exactly as a loop construct might model
a (real-world) iterative process.  If your model (view) requires that a class
is constructed by inheriting two other classes (i.e., the new class has all
the properties of both these classes, with equal importence being given to
both sets of properties), then you cannot reasonable do anything else than use
multiple inheritence - unless you can revise your model.

Multiple inheritence can (and does) cause problems, but only if abused (as can
virtually any programming construct yet invented).  More up-front thinking is
needed - how should a new class relate to existing classes?, how should it be
used and re-used?

Suppose we want to model a new motor vehicle, being at the same time a
sports car and an off-road vehicle.  We can list the major attributes of
both vehicle-classes, add them together, and we've got our off-road sports
car - multiple inheritence seems to reflect this relationship perfectly 
(possibly with repeated inheritence).  On the other hand, if we just
wanted to create a sports-car with 4-wheel-drive, inheriting from both
these classes seems inappropriate - rather create a sport-car descendant
that has 4-wheel-drive as an attribute (possibly by redefining the `final-drive
'
attribute).

Without MI, in the first case we'd need to make off-road-vehicle an attribute
of the sport-car descendant class, which seems wrong.  Whereas using MI in the
second case - if we inherited from sports-car and 4-wheel-drive, we'd end-up wi
th
a class that polymorphism would allow us to use in place of 2-wheel-drive as so
me
other vehicle's `final-drive' - that would look really wierd!

It may be that MI might be to OO languages what pointers were to C - the greate
st
power and the greatest danger.

--
Roy Phillips
A+F SystemEntwicklung
W-4030 Ratingen
Germany
roy@alfrat.de
{world}!mcsun!unido!alfrat!roy

Re: Multiple Inheritance in Ada 9X

[mcsun!fuug!news.funet.fi!sunic!ugle.unit.no!nuug!ifi.uio.no!holmenkollen!]

> Multiple inheritance is the feature that allows you to define queueing trucks
 as
> things that are at the same time
> * trucks and
> * elements in a queue
> Is that correct ?

Sorry, not true.   In Simula you do  this by subclassing "truck" under
"element in queue", thus all trucks are queue elements or none of them
are.

In other words:  Simula doesn't have multiple inheritance.

--
                                                    (Rmz)

Bj\o rn Remseth   !Institutt for Informatikk    !Net:      rmz@ifi.uio.no
Phone: +472 453466!Universitetet i Oslo, Norway !NeXTmail: rmz@neste.ifi.uio.no