Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!rex!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!otc!metro!basser!usage!elecvax!cheops!marku
From: marku@cheops.eecs.unsw.oz (Mark Utting)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel questions
Keywords: assertions, types, is-a inheritance, export, genericity
Message-ID: <1301@cheops.eecs.unsw.oz>
Date: 31 Aug 89 05:20:46 GMT
References: <1567@laura.UUCP> <191@eiffel.UUCP> <1573@laura.UUCP>
Organization: EE & CS, Uni N.S.W., Sydney, Australia
Lines: 52

From article <1573@laura.UUCP>, by guendel@exunido.uucp (Andreas Guendel):
> In my first posting I claimed:
> 
>> Another point is the multiple-inheritance problem. As in the book this
>> feature is often used for implementation convienience: there is no way
>> to argue that a fixed-stack "is-a"n array.
> 
> If fixed-stack is implemented as a subclass of array, the type-checker will
> assume that an instance of fixed-stack can be used wheresoever an array is
> expected. But if you do that at any place, the algorithm given by Meyer to
> make Eiffel type-save will raise an error since NO function on arrays can
> be called on fixed-stacks. As I understood this algorithm it should be used
> in situations where a class NEARLY CONFORMS to the specification of its
> superclass but has SOME methods with restricted argument-types or which are
> hidden to ensure the integrity of the subclass's instances state.
> 
> Andreas

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.

Some object oriented languages do have both kinds of inheritance, and
several papers I have read have stated that it is desirable to distinguish
between these different uses of inheritance.  There is a good discussion
of various inheritance relations in "Inheritance as an Incremental 
Modification Mechanism" or "What Like Is and Isn't Like", by Peter Wegner and 
Stanley Zdonik in ECOOP '88 proceedings (LNCS 322, Springer-Verlag).

Extending Eiffel to distinguish between `normal' inheritance (which in 
Eiffel is more or less SUBTYPE inheritance) and REUSE inheritance would
add to the type security of the language, by allowing programmers to
specify when they do not wish a child to have to be compatible with one of
its parents.  There was a posting to this newsgroup early this year from
a company using Eiffel for very large systems which said they were doing
exactly this, informally.  From memory, they just put a comment "-- USE"
before some of the class names in the `inherit' clause.


Mark Utting, Dept.Comp.Sci, UNSW, PO Box 1, Kensington, NSW, Australia 2033
   //		ACSnet,CSNET:	marku@cheops.unsw.oz
  //		BITNET/ARPA:	marku%cheops.unsw.oz@uunet.uu.net
\//		UUCP:		...!uunet!munnari!cheops.unsw.oz!marku