Re: Ada 90 inheritance request?

[stt@dsd.camb.inmet.com (Tucker Taft)]

In article <JGOODSEN.94Dec13140247@treasure.radsoft.com>,
John Goodsen <jgoodsen@treasure.radsoft.com> wrote:

>I am dismayed at how anyone could look at this so-called "solution" to
>multiple inheritance and walk away comfortable that Ada9X properly
>supports MI.  The lack of *direct* support for MI in Ada 9X, is IMHO,
>a serious foobar that has to this point been explained away by the
>ivory tower language designers ...

Feel free to accuse of us of all kinds of crimes against nature,
but please don't put us in an ivory tower ;-).  I trust that those
who know me recognize that I tend to live more in the cement dungeon
of language design, scrabbling around in the cement dust of human
engineering, implementation concerns, efficiency, etc.  
The Ada 9X mapping/revision team consisted almost entirely of dedicated, very 
experienced, Ada and other-language programmers with a strong penchant 
for designing the most productive, reliable, readable, and usable language 
they knew how, given the constraints of the process.

An easy to use, intuitive, efficient, straightforward, multiple inheritance
mechanism in Ada 9X would have been great.  Unfortunately, we have never
seen such a beast.  Perhaps you have.  What we found when investigating
ways to support multiple inheritance was that everybody knew what was
the best way to do it -- their own way!  When we have encountered such
things in the past during language design, the conclusion to be drawn
is that implementing multiple inheritance is still a *programming* problem,
not a language design problem.  If even two existing OOP languages did
Multiple Inheritance the same way we would have seen that as a reasonable
starting place.  But the fact is that the rules for dealing with the
inevitable additional complexities of multiple inheritance are different
in essentially every langauge we looked at.  Even Sather and Eiffel, which
otherwise have a lot in common, differ in how they resolve the MI issues.
C++ in its usual pragmatic way provides two different ways to do MI,
using regular or virtual base classes.  CLOS just merges based on names
and a search order for methods.  Eiffel provides renaming.  Etc...

By constrast, all of the languages agree on how to do single inheritance
in the language, and it is essentially unchanged since the days of 
Simula '67.  It is intuitive, efficient, straightforward, reliable,
type-safe, productive, useful, ...  That sounds like a feature for
Ada ;-).  Note that Smalltalk, Object Pascal, Modula-3, Oberon-X,
and Objective-C all have chosen to stick with single inheritance.
There are (ivory tower ;-) researchers studying ways to add MI in 
some of these languages, but the practitioners seem to be plowing
ahead very productively and happily relying on the rock-solid
single inheritance, building up their conceptual multiple inheritance
hierarchies as they see fit, in an application-specific way.

We expect that most Ada 95 programmers will find the same thing.
Single inheritance is there, in its full glory and simplicity,
right in the language.  In addition, there are building blocks
for constructing robust application-specific solutions to problems
that might otherwise use a language-provided multiple inheritance
mechanism.

Furthermore, what happens in some cases, is that the language-provided
multiple inheritance mechanism turns out to be not quite the right
solution for a given problem that is "reminiscent" of multiple inheritance.
Then you have the worst of both worlds -- a language made more complex
by the addition of linguistic multiple inheritance, and an application made 
more difficult by the lack of appropriate building blocks for solving the
problem the "right" way.

To summarize, it is our view that it is a bit ivory-towerish to
look at a language, and say that if it doesn't have feature X implemented
in some specific way, then it is useless and FUBAR.  I can't tell
you how many times we have been threatened over the past 5 years with
similar statements about all kinds of obscure features.  It is interesting
to follow the C++ standardization process, where the same desparate
statements are made in support of one obscure feature after another.

The fact is that a good language has its own self-consistent logic,
and some features make a good addition to that structure, and others
just don't fit.  We couldn't find a language-provided multiple inheritance
mechanism that enhanced Ada.  We could find plenty that made it more
complicated, less intuitive, less reliable, less readable, etc.
We welcomed proposals and suggestions for one that would be a net
addition to the language, but on deeper investigation into the nitty-gritty, 
we never found one where the pluses outweighed the minuses.  We had 
an "ivory-tower" desire to try to find one, but we had a more practical 
concern that we didn't want to FU the language to get one in, just for 
the marketing potential.  We wanted the features to be useful and 
reliable, not just there for show.  Perhaps the designers of 
Ada 007 will find the silver bullet...  Meanwhile, we will be productively
building reliable systems in our cement basement.

>John Goodsen                         Currently on-site at:
>The Dalmatian Group                       JP Morgan 
>User Interface Specialists                60 Wall St., New York City
>jgoodsen@radsoft.com                      jgoodsen@jpmorgan.com

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138