NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/ada/2496

Text File | 1992-08-31 | 4.0 KB | 82 lines

Newsgroups: comp.lang.ada
Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!linus!linus.mitre.org!linus!mbunix!eachus
From: eachus@Dr_No.mitre.org (Robert I. Eachus)
Subject: Re: MI - clutching at straws
In-Reply-To: [e-mail]'s message of Mon, 31 Aug 92 15:36:41 GMT
Message-ID: <EACHUS.92Aug31155744@Dr_No.mitre.org>
Sender: [e-mail] (News Service)
Nntp-Posting-Host: dr_no.mitre.org
Organization: The Mitre Corp., Bedford, MA.
References: <EACHUS.92Aug23173050@Dr_No.mitre.org>
    <[e-mail]>
Date: Mon, 31 Aug 1992 20:57:44 GMT
Lines: 67

In article <[e-mail]> [e-mail] (Peter Klein) writes:

   It is important to keep in mind that genericity and inheritance are
   orthogonal concepts (see Betrand Meyer's "Genericity versus Inheritance,
   Journal of Pascal, Ada, & Modula-2, Vol. 7, No. 2, pp. 13-30,
   Wiley 1988 on this). In restricted cases, one can be simulated by
   the other. But this is pointless when we talk about the usefulness
   of the concepts as such.

   They are different, agreed, but your conclusion does not follow.
You asked how something could be done without MI.  If it can be be
done using generics, then that is direcly related to the usefulness of
generics and inheritance.

   What actually is lost when simulating inheritance with genericity
   is polymorphism. In your example, the implementation of the extensions
   is hidden from the base type. But the implementation of the basic
   type reveals *which* extensions are planned. This has some severe
   disadvantages...[Examples deleted.]

   This is why single inheritance is in Ada 9X.  Extensions not
dreamed of when the original parent was declared can be provided using
type derivation.  But the cases where you need two incompatible
extensions to the same parent to be merged, while they can be created
as examples, are the kind thing that respectable software engineers
avoid like the plague.  Assume that you have some random abstarct type
foo, and two extension of it. One makes lists of foos, and another
creates trees of foos with a sort key.  A program which takes objects
from lists and inserts them into trees makes sense and can be written
naturally without MI).  A program which has objects which are
simultanously in lists and trees, and uses MI to manage both
structures is a mess.  Such a program can be created and made to work,
but the list primitives will have to be aware of the tree primitives
and vice-versa.

   In a more general sense, it cannot be reasonable to extend a basic type
   by inheritance or by genericity depending on the fact whether you want
   to combine some extensions later on. If you think that the extensions
   should be done by inheritance, you'll end up missing MI if you want to
   combine extensions on a higher level. On the other hand, if you say that
   the extensions should be done using genericity, you won't need MI. But
   in this case, you don't need inheritance at all.

   Close.  IMHO inheritance is one of the least important OO features
being added to Ada 9X, but as I mentioned above it does have its uses.
In Ada 9X as in Ada 83, generics will be a much more powerful tool,
and should be the tool of choice in many areas where inheritance is
naturally used in other OO languages.

   Eighty years ago automobiles had more wood in them than metal,
today's cars contain little or no wood.  Should we conclude that
modern cars are inferior because the manufacturing plants no longer
have wood finishing facilities?  (Or because the cars no longer have
buggy whip holders? :-) In my book, multiple inheritance has never
been of more than marginal usefulness.  In a language with generics
the best solution for any particular problem never seems to use MI, so
let's leave it behind with the rest of the excess baggage, such as
call by name.


--

                    Robert I. Eachus

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