🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #5896

Re: object oriented design decision

#5896
From: Barry Margolin
Date: Wed, 23 Nov 1988 18:36
40 lines
2423 bytes
In article <10660@tekecs.TEK.COM> paulsc@radio_flyer.UUCP (Paul Scherf) writes:
>but I haven't seen anything that shows that multiple inheritance
>really adds anything.
>
>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.

This has a few problems.  One is that each time you think of a new
dimension you must modify the vehicle class in order to add a new
instance variable to embody that dimension.

A more serious problem is that these sub-instances are running with
the wrong notion of "self".  If they perform an operation on self they
will not be operating on the whole vehicle, just their own aspect.
"Self" is a very important concept in OO programming, as it allows a
method in a component class to perform an operation whose results
depend on the actual class of the object.

With this workaround for the lack of multiple inheritance, each
sub-instance must either have an instance variable holding its parent,
or every operation must pass the parent as an argument.  But you would
also need the grandparent, the great-grandparent, etc.  Multiple
inheritance automates and generalizes this in an elegant manner.

By the way, your suggestion can actually be used as an argument
against inheritance in general, since the same mechanism could be used
to pass on operations from a class to a single superclass.  I believe
there are some OO systems that work this way.  I don't know how they
deal with the "self" issue.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
Technical Details
Message-ID: <32099@think.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!think!barmar
References: <4086@enea.se> <11522@cup.portal.com> <12636@steinmetz.ge.com> <10660@tekecs.TEK.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: object oriented design decision
Message-ID: <32099@think.UUCP>
Date: 23 Nov 88 18:36:37 GMT
References: <4086@enea.se> <11522@cup.portal.com> <12636@steinmetz.ge.com> <10660@tekecs.TEK.COM>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 40