Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ginosko!uunet!mcsun!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.eiffel
Subject: Re: Kinds of inheritance (was: Eiffel questions)
Keywords: assertions, types, is-a inheritance, export, genericity
Message-ID: <1317@tukki.jyu.fi>
Date: 18 Sep 89 07:37:12 GMT
References: <1567@laura.UUCP> <191@eiffel.UUCP> <1573@laura.UUCP> <1301@cheops.eecs.unsw.oz> <1268@tukki.jyu.fi> <1283@cs.rit.edu>
Reply-To: markku@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 71

In article <1283@cs.rit.edu> mjl@isc.rit.edu writes:
- [...]
-In article <1268@tukki.jyu.fi> Markku Sakkinen writes:
->
->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.
-
-What am I missing here?  In Eiffel, you can certainly have an
-unexported attribute that's an array, and if it's Created when the
-fixed stack object is Created, it will be non-shared (unless you do
-strange Cloning).  And why is such an array any less "permanent" than
-one that is directly contained in the in each object:  from a client's
-view, the stack storage comes into being when the object is Created,
-and is lost when the object is Forgotten.

I guess you are right concerning Eiffel (in contrast to many other OOPL's):
permanency can be ensured by using a "once" function to create the array.
Keeping the array completely invisible outside the fixed stack requires
a little discipline in defining and programming the public features,
but that is a small matter. - This actually makes me wonder even more
why Meyer wanted to apply multiple inheritance to this case!

->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.
-
-You seem to be equating incidental inheritance with REUSE inheritance.
-If so, why is the following not valid SUBTYPE inheritance?
-
-Suppose I have a class VEHICLE, and subclasses of this called CAR and
-TRUCK.  I may want to model a small van as both a CAR and a TRUCK,
-kicking in repeated inheritance.  We get the following class
-hierarchy:
-
-	     VEHICLE
-	        /\
-	       /  \
-	     CAR TRUCK
-	       \  /
-	        \/
-	       VAN
-
-I'd argue that a VAN is a subtype of CAR, TRUCK, and VEHICLE, exposing
-different aspects of its nature under all these guises.

Sorry, I should have made myself clearer. I mainly meant _direct_ repeated
inheritance in the terminology of OOSC; but also _indirect_ repeated
inheritance if it causes a repetition on the _instance_ level.
(The indirect case may happen in any language that suports MI,
but I have not seen the direct case in any other language than Eiffel.)
In your example, a VAN instance is exactly one VEHICLE instance,
so this is true subtyping. - In my paper, I criticised the similar-looking
example from OOSC ("transcontinental drivers", p. 275-277),
because there a FRANCE_US_DRIVER instance contains "one and a half"
DRIVER instances.

-Mike Lutz
-Rochester Institute of Technology

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