Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!rit!mjl
From: mjl@cs.rit.edu
Newsgroups: comp.lang.eiffel
Subject: Re: Kinds of inheritance (was: Eiffel questions)
Keywords: assertions, types, is-a inheritance, export, genericity
Message-ID: <1283@cs.rit.edu>
Date: 11 Sep 89 21:36:46 GMT
References: <1567@laura.UUCP> <191@eiffel.UUCP> <1573@laura.UUCP> <1301@cheops.eecs.unsw.oz> <1268@tukki.jyu.fi>
Sender: news@cs.rit.edu
Reply-To: mjl@isc.rit.edu
Organization: Rochester Institute of Technology, Rochester, NY
Lines: 74

This is actually a followup to both Mark Utting and Markku Sakkinen.

In article <1301@cheops.eecs.unsw.oz> Mark Utting writes:
>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.

This seems about right to me, but as Markku has noted, the fixed
stack could be a client of array, rather than an heir.  In general,
though, this can make it difficult to mirror the class semantics
cleanly, and REUSE inheritance would be nice.  Note that C++ 2.0 (flame
retardant:  I'm no great C++ fan) can handle REUSE via "private"
inheritance.  That is, if class C inherits from B "publicly", then all
C's are B's, and one can assign a C to a B.  If the inheritance is
"private", then C is just using B's functionality, and their types are
independent.

This seems to capture the two forms of inheritance, though the
terminology (public/private) is a bit baroque.  Given that multiple
inheritance is an integral part of the Eiffel development model, I'd
also like to see these two forms kept distinct.

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 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.

Mike Lutz
Rochester Institute of Technology
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!ritcv!mjl
CSNET:		mjl%rit@relay.cs.net
INTERNET:	mjl@cs.rit.edu