Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!quintus!pds
From: pds@quintus.uucp (Peter Schachte)
Newsgroups: comp.lang.misc
Subject: Re: object oriented design decision
Message-ID: <737@quintus.UUCP>
Date: 24 Nov 88 01:34:33 GMT
References: <4086@enea.se> <11522@cup.portal.com> <12636@steinmetz.ge.com> <10660@tekecs.TEK.COM>
Sender: news@quintus.UUCP
Reply-To: pds@quintus.UUCP (Peter Schachte)
Organization: Quintus Computer Systems, Inc.
Lines: 54

In article <12636@steinmetz.ge.com> halverson@crd.ge.com (Pete Halverson) writes:
>From my experience, multiple inheritence seems to be most useful when
>you're trying to represent characteristics that are somehow orthogonal,
>i.e. land vehicles vs. sea vehicles, motorized vs. non-motorized, military
>vs. commercial.  Single-inheritance-only schemes require you to define a
>separate class for each combination (i.e. Motorized-Military-LandVehicle,
>NonMotorized-Commercial-SeaVehicle).   If you have many dimensions and many
>subclasses, the resulting cross-product is going to get real nasty, real
>fast.

In article <10660@tekecs.TEK.COM> paulsc@radio_flyer.UUCP (Paul Scherf) responds:
>Couldn't you have one vehicle class with 3 instance variables?
>One instance variable for each of the "dimensions"
>(e.g.  surface: land vs. sea, propulsion: motorized vs. non-motorized, ...).
>The vehicle class could forward messages to the appropriate instance variable.
>Some OO languages allow methods to be expanded in line,
>and can often avoid the extra method lookup,
>so that the forwarding wouldn't have to incur a run time penalty.

I see two problems with this approach.  First, it's a pain to define
lots of methods for vehicle that just forward the message to the
appropriate instance variable.  More seriously, though, the object
receiving the message is no longer the one you're really talking about,
so self messages go to the wrong place.  For example, suppose vehicle
has a position message that returns the vehicle's position, and both
motorized and non-motorized define a halt method.  Further suppose that
in one or both cases, halt needs to know the vehicle's position.  The
obvious way to do this is to send a position message to self.  But this
won't work, because self is motorized or non-motorized, rather than the
vehicle.

Well, you can patch around this by having a back-pointer from motorize
and non-motorized to the vehicle, and having methods for all of
vehicle's messages that forward to the vehicle.  That of course means
that you have to have a separate motorized object for every motorized
vehicle you create.  It starts getting ugly.

I think a similar approach could work quite well, though, if it were
built into the OO system.  It would have to understand attributes, like
propulsion in the above example.  An attribute would be like a class,
except that they can't be instantiated, and a class can specify that
certain attributes must be specified when it is instantiated.  So vehicle
would be a class that requires propulsion, which would be an attribute
(sort of like a mixin, for flavors people).  An attribute specification
would include a set of methods that its instances (this is probably a
bad choice of word -- in this case I mean motorized and non-motorized)
must supply.  When an instance of vehicle it gets all the methods from the
vehicle class, plus the methods from the chosen attribute.  But it's
still a single object.

I hope I'm being at least faintly clear.
-Peter Schachte
pds@quintus.uucp
..!sun!quintus!pds