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=-0.0 required=3.0 tests=BAYES_20 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 29 Dec 91 00:15:11 GMT
From: netcomsv!objsys@apple.com  (Object Systems)
Subject: Re: Multiple Inheritance in Ada 9X
Message-ID: <1991Dec29.001511.8007objsys@netcom.COM>
List-Id: <comp.lang.ada>

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