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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 14 Sep 92 20:19:42 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: MI - clutching at straws
Message-ID: <EACHUS.92Sep14151942@Dr_No.mitre.org>
List-Id: <comp.lang.ada>

In article <1992Sep9.142434.3940@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.inf
ormatik.rwth-aachen.de (Peter Klein) writes:

 > Unfortunately, your arguments don't hold in my example, where several
 > extensions of the same base type are combined. The resulting type is
 > essentially the base type augmented by an arbitrary subset of the possible
 > extensions. The problems you mentioned cannot arise in this context.
 > Furthermore, it is pretty awkward to simulate such behaviour without MI.

    But it is exactly that case...the (base) type is extended with lists
and trees, and then these extensions are combined.  (It is hard not to
use nasty words to relieve frustration at this point, but I know that
this is a hard enough to understand mechanisms like type extension and
inheritance, and the subtile differences in mechanisms discussed here
tend to rapidly convert any brain into jelly, but bear with me.)
   
    Part of the problem is semantic.  I think Tucker will be glad to
explain to you how Ada implements multiple inheritance, while most of
us use MI to mean something other than generic instantiation, but
Tucker does have a point.  The Ada 9X mechanisms are safer and more
general than those offered by most instances of MI, but it does
require more thinking up front by the designer of a mix-in.

 > Not true. Inheritance is the more powerful feature. Dynamical binding cannot
 > be done with genericity; you'll never get true polymorphism without
 > inheritance. But I don't think this is the question. Genericity and
 > inheritance both have their uses, and most of the time the design makes
 > clear which of them is appropriate in a given situation. If you think that
 > inheritance is not *really* needed, I can accept that. But my original
 > question was: What do I loose when I have SI only?

     I assume that you left a word out above, since in my post I did
say that inheritance is sometimes necessary, it is union style
multiple inheritance that is unnecessary in Ada or any other language
with sufficiently powerful generic capabilities.

 > In what way does the lack of MI affect the usefulness of the whole
 > inheritance idea? *If* I think extensions of a base type should be
 > done using inheritance, how do I solve the problem of combining
 > independent extensions afterwards?

     You don't.  But in general it is always wrong to combine
extentions which were not intended to be combined.  Ada 9X will give
you a choice of several combining styles, and in general the language
will insure that mixtures which are permitted will work.  However,
since generics mean that the difference between a combining extension
and normal single inheritance is a few words, you should honor the
wishes of the type designer and assume that two types which can't be
mixed shouldn't be mixed:

      with Parent;
      package New_Abstraction is
        type Child is new Parent.Abstraction with private;
        -- syntax under construction, very subject to change.
        ...
      private
        ...
      end New_Abstraction;

      with Parent;
      generic
        type Abstraction is new Parent.Abstraction;
        -- see note above on syntax
      package MixIn is
        type Child is new Abstraction with private;
        ...
      private
        ...
      end MixIn;

     Now New_Abstraction uses single inheritance and can't mix with
another similar extension. MixIn, with just a few lines different in
its specification, can mix with similar type extensions OR with
New_Abstraction: 

     with New_Abstraction, MixIn;
     package Mixed_In is new MixIn(New_Abstraction.Child);

     (Note that if you do this, the body of MixIn can access the
operations of its parent, in this case New_Abstraction.Child, as can
users who with Mixed_In.  However, if Mixed_In hides an operation of
New_Abstraction.Child, whether or not dispatching is involved, the user
will have to with New_Abstraction and do a type conversion to access
the "parent" operation.)

     If it weren't for the fact that generics are IMHO a much more
powerful tool than inheritance, I could argue that using generics to
implement mix-ins is like using a sledgehammer to swat flies.  But
since Ada has all of the necessary support for generics for other
reasons, it seems silly to talk about adding MI because maybe someday
someone will think of an application where classical MI is
significantly better.  (In my opinion, and that of a lot of other
software engineers, the ability to express "Watch it!" in the code is
a definite advantage.  In Ada 9X using inheritance in a non-generic
fashion will be a strong warning message that this new type has more
than mix-in semantics.)

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...