Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!brutus.cs.uiuc.edu!render
From: render@brutus.cs.uiuc.edu (Hal Render)
Newsgroups: comp.object
Subject: Re: Inheritance is NOT Delagation (sic)
Summary: yeah, but delegation isn't inheritance either.
Keywords: delegation, inheritance, object-oriented
Message-ID: <1989Oct13.020914.2811@brutus.cs.uiuc.edu>
Date: 13 Oct 89 02:09:14 GMT
Sender: news@brutus.cs.uiuc.edu
Reply-To: render@cs.uiuc.edu
Distribution: comp
Organization: U of Illinois, CS Dept., Systems Research Group
Lines: 114

david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes:
>1) Inheritance violates encapsulation by the superclasses, therefore
>2) Inheritance makes concurrency more difficult in the resultant system.

Point one is arguable.  If the "violation" you point out is the dependency 
of the structure and behavior of subclass on that of its superclass, then 
I agree that encapsulation has been violated.  However, how is this different
from the dependence between an object that delegates to another object?
In one case you are sharing actual definitions, but behaviorally the 
dependence seems much the same.

As for point two, I'd have to hear a better argument than proof by
statement.

>Note: "Actors" which is the most widely accepted language concept for
>concurrent object programming, DOES NOT support concurrency.

Do you mean Actors doesn't support INHERITANCE?  If not, then the 
above statement does not make sense.  If so, it still is not a proof of (2).

>Using delagation, one builds a complex "object" through grouping
>several different small objects together.  Each small object maintains
>its own address space and thread.  The complex object is only
>conceptual.
>Delagation reflects reality better than inheritance:  your car does not
>inherit from door, tire, and engine: is is a composite made up of
>doors, tires, and an engine.  The fact that the window on the left door
>is open should have no bearing on the state of other windows or the
>fuel injection or tire pressure.

What you have just said makes no sense.  Your confusing a part-of 
relationship (aggregation of subparts into a whole) with a kind-of
relationship (the sharing of common properties by similar objects).
True, there is a similarity in the implementation mechanisms, but the 
conceptual meanings are different.  With your example, the idea of 
inheritance in conceptual modeling of a car is better demonstrated by 
multiple inheritance hierarchies, one for each of the major parts.  
Assuming all connections are compatible, you'd have a specialization 
hierarchy for chassis, engine, door, etc.  Car would be an abstract 
class with abstract components Chassis, Engine, LeftDoor, RightDoor, 
Wheels, etc.  You could then define a concrete subclass of Car with 
concrete component classes.  For example, you might define the SportsCar 
subclass of Car with RacingChassis, TurboEngine, SportWheels and so on 
as concrete component classes.  This is just one way to use inheritance 
and part-of relationships.

>Concurrency is more cleanly supported with Delagation than with
>Inheritance.  Imagine a Car class built using multiple-inheritance.
>Building the car would require the constructors to be invoked serially,
>OR the programmer would have to be concerned about critical sections
>and the like.  As we all know, critical sections are notoriously hard
>to find and debug.  The reason time sharing systems are so easy to use
>is this: all of the processes get their own address space.  The
>encapsulation provided by objects is exactly the same, but the
>granularity is finer.  This leads to more effective use of
>multi-processors and multi-threaded processes (ala Mach).

Concurrency is a function of run-time behavior; inheritance is (mostly)
an issue compile-time structure.  Concurrent message-passing is done
between instances whose structure has already determined and which have
their own local storage, so how that structure was determined is a null
issue.  Or do you think that inheritance means you share data slots with 
your parent?  If so, maybe you have the wrong idea about inheritance.

BTW, I believe they used Objective C to code Mach, and I'm pretty sure
that Objective C has inheritance.  Of course, the conceptual model of 
the language that you code a system in and the conceptual of the system
are two different things, but it just shows that inheritance isn't
totally worthless.  

>In fact, one can think of the object universe which represents the
>typical object-oriented application as being a bunch of delagating
>objects.

Yes, but I think that this is because delegation is a more primitive 
mechanism than inheritance.  Although I don't know if it has been tried,
you can probably show that you could implement inheritance with
delegation.  Of course, you can implement delagation with a Turing machine,
but this doesn't mean I want to program using one.

>The average depth of inheritance in most systems is about 3.  The
>number of object types in many systems is very large, in the dozens to
>thousands.  Therefore, people tend to favor delagation over inheritance
>by a large margin, even when they don't consider it to be an issue.

I'm curious where you that number.  I don't necessarily disbelieve it, 
I just wonder where it came from, since  I'd be surprised for large 
systems written in class-oriented languages to have such a shallow tree.
Still, the part-of relationship is as important as the kind-of relationship
so it wouldn't suprise me overly much.

>Can you imagine the nightmare which would result if all the objects in
>YOUR application were cobbled together via inheritance into a single
>object type?  Barfo dude!  Sure, a graduate student can "prove", that
>"Inheritance IS Delagation" but is is obviously the inferior form of
>the duality.

What wrong with treating a collection of objects as an instance of
a single class?  That seems to be your implication.  Sure, a car is 
a collection of parts, but you can have more than one car, each with 
its own engine, doors, wheels and chassis, so it seems logical to 
have a class Car to describe many instances of an aggregation of parts.
I think a programming language would be inferior that made me do more work
than another to implement a useful modeling concept, namely inheritance
and the kind-of relationship.  Delegation is nice, but I don't think
it proves inheritance to be an unsound concept. 

>Lynn Stein would have met with alot of disagreement if that paper was
>presented at OOPSLA '89.

Possibly, but I hope it would have been from people who had read it 
and had reasonable arguments.  Perhaps you should give it a read, dude.

hal.