Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!mcsun!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.eiffel
Subject: Kinds of inheritance (was: Eiffel questions)
Keywords: assertions, types, is-a inheritance, export, genericity
Message-ID: <1268@tukki.jyu.fi>
Date: 4 Sep 89 11:44:36 GMT
References: <1567@laura.UUCP> <191@eiffel.UUCP> <1573@laura.UUCP> <1301@cheops.eecs.unsw.oz>
Reply-To: markku@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 56

Andreas Guendel (guendel@exunido.uucp) has recently posted a couple
of very pertinent articles in this group.
Look them up; I will not directly quote them here.

In article <1301@cheops.eecs.unsw.oz> marku@cheops.eecs.unsw.oz (Mark Utting) writes:

>In my research work on verifying systems that use multiple inheritance
>I have found that it is semantically useful to distinguish between
>`SUBTYPE' inheritance (eg. CHILD1 is a subtype of PARENT) and `REUSE'
>inheritance (eg. CHILD2 shares PARENT's implementation or specification).
>
>Practically, the difference is that CHILD1 objects are intended to behave 
>like PARENT objects, whereas CHILD2 objects may behave *quite* differently.
>This means that the type system should not allow CHILD2 objects to be assigned
>to PARENT variables (because they are not *intended* to behave similarly).
>
>In the above example, it is my opinion that `fixed-stack' should inherit 
>from `array' via REUSE inheritance rather than SUBTYPE inheritance.

[The example is from Meyer's "OOSC": 10.4.1 "The marriage of convenience"
(p. 241). It is the very first example of multiple inheritance presented
in the book.]

I made a similar distinction as Utting in my paper "Disciplined Inheritance"
at ECOOP'89 (proceedings published by Cambridge University Press),
the terms used there are 'essential' and 'incidental' [inheritance].
I also presented some reasons why most OOPL's require programmers to use
"inheritance" even in the cases where the interfaces of the superclass
and the subclass have nothing in common. (In this respect, CLU, Ada
and Modula-2 are better off!)

So, why cannot a FIXED_STACK object simply have an ARRAY object as
a component, but FIXED_STACK must "inherit" ARRAY? Because in Eiffel
(and most other object-oriented languages) one cannot declare some
desirable restrictions otherwise:
1. Each FIXED_STACK object must have a _permanent_ ARRAY part.
2. ARRAY parts must not be shared or otherwise visible outside
   the FIXED_STACK objects.
In those OOPL's that allow objects to be _directly contained_
within other objects (e.g. C++, EXTRA), these problems practically disappear
and programmers can avoid abusing "inheritance".
On the other hand, in weakly typed languages like Smalltalk one cannot
even specify the class of any component (instance variable) of an object,
so there a still greater need to apply "incidental" or "reuse" inheritance.

I would like to point out that these problems are not caused specifically
by _multiple_ inheritance. Nevertheless, if you have multiple inheritance,
you can use inheritance more liberally. Repeated inheritance, a specialty
of Eiffel, must logically always be "incidental", as argued in my paper.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland