Xref: utzoo comp.lang.c++:3347 comp.lang.eiffel:193 comp.lang.smalltalk:1081
Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!e260-4d.berkeley.edu!labc-4da
From: labc-4da@e260-4d.berkeley.edu (Bob Heiney)
Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk
Subject: Re: Use of inheritance for classification?
Message-ID: <24537@agate.BERKELEY.EDU>
Date: 17 May 89 23:53:16 GMT
References: <30582@apple.Apple.COM> <6365@brunix.UUCP> <DLD.89May15164346@F.GP.CS.CMU.EDU> <6685@brunix.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Organization: University of California, Berkeley
Lines: 73

In article <6685@brunix.UUCP> bpe@cs.brown.edu (Page Elmore) writes:
>If you have the types such as:
>
>       Type Car
>          ^    Property: color: allColors (type with instances of all colors)
>          |    Method:   Paint(newColor: allColors)
>          |
>          |
>       Type Honda CRX (inherits from Car)
>               Property color: blueBlack (type with blue and black instances)
>
>
>where Type Car defines a property color which has as it's value type allColors
>and also has a method Paint which takes as its argument an instance of
>allcolors. ...
>The Paint method will fail on those objects which are
>Honda CRX's.
>
>Now you will probably say that you should redefine Paint on Honda CRX
>as Paint(newColor:blueBlack) and only accept the correct colors.  This
>only makes matters worse however because now you have "broken" the code
>which was trying to paint the set of cars (some of which are Honda's)
>some new color. ...

Here we have a conflict that seems to me to be coming from expecting to
impose too much generality on a situation.  In trying to constrain everything
to just one metaphor, we're confusing ourselves.

Certain problems work well with inheritance as specialization of a general
class.  For example, all windows in a window system need to be able to
move to an x,y coordinate, draw themselves, etc.  Here plain old inheritance
works fine.  The windows have compatible features.

But sometimes we want to inherit from a class not because we want to be
compatible with the class, but because we want to extend its services.
For example, BI_LINKABLES which implement two way lists in Eiffel inherit from
LINKABLES.  Now it doesn't make any sense to link a LINKABLE to a BI_LINKABLE
list, so the function that makes links is more specific in BI_LINKABLES than
LINKABLES.  I guess you could say that LINKABLES are really a "subset" of
BI_LINKABLES, but then you still can't link to the left.  The reason
we want to inherit from LINKABLE is not that we want to be treated as
LINKABLEs, but that most of the features of a LINKABLE are things we'll need.
We're inheriting for ease of coding, not for classification.  Our client is the
LINKED_LIST package (only) and it "knows" about the services a BI_LINKABLE
offers.  It needs to know something, whereas a window system could care
less about the features a particular window offers for the most part.

Gettting back to our Hondas, we need to consider how we're using this class.
Since with this example we do seem to want classification, we might provide
another feature in addition to Paint.  A query function,

	Paint_Available(color:allColors) : Boolean 

would be good.  Then a client can ask a Honda if you can paint it a certain
color, and then a precondition of Honda's Paint would be:
Paint_Available(color).

In otherwords, if a feature is a desired property of all descendants
of a class, but not compatible in all descendents of a class, the base
class should provide queries.  If a feature is "like" (note Eiffel
keyword) one in one of its ancestors, but isn't compatible, assume
that the client knows what it's doing, like BI_LINKABLES do.

We're confused because we're using one structure to represent
both simile and metaphor, both "IS_LIKE_A" and "IS_A".  A HondaCRX IS_A car,
but a BI_LINKABLE IS_LIKE_A LINKABLE.

Hope I didn't muddy that waters too much,
-------------------------------------------------------------------------------
| Bob Heiney                         "And in the end, the love you            |
| labc-4da@rosebud.Berkeley.edu       take is equal to the love you make."    |
|                                                     -- The Beatles          |
-------------------------------------------------------------------------------