david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (10/13/89)
In article <17653@brunix.UUCP> sdm@norton.UUCP (Scott Meyers) writes: >In article <125984@sun.Eng.Sun.COM> grover%brahmand@Sun.COM (Vinod Grover) writes: >>I once read that the inheritence mechanism is a special case of a more >>general phenomena called Delegation. I cannot come up with the reference >>but unless I am mistaken I think it was an article written by Stefik and >>Bobrow in the AI Magazine a few years ago. > >Lynn Stein, a graduate student here at Brown, proved that delegation and >inheritance are equivalent. Hence, inheritance is not a "special case" of >delegation. For the proof, see her paper in the OOPSLA '87 Proceedings: >"Delegation Is Inheritance." Delagation is better than Inheritance, because 1) Inheritance violates encapsulation by the superclasses, therefore 2) Inheritance makes concurrency more difficult in the resultant system. Note: "Actors" which is the most widely accepted language concept for concurrent object programming, DOES NOT support concurrency. 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. 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). In fact, one can think of the object universe which represents the typical object-oriented application as being a bunch of delagating objects. 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. 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. Lynn Stein would have met with alot of disagreement if that paper was presented at OOPSLA '89.
pallas@Neon.Stanford.EDU (Joe Pallas) (10/13/89)
In article <6219@jpl-devvax.JPL.NASA.GOV>
david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes a very confusing
explanation of why he thinks something which is not inheritance is
better than something which is not delegation.
I only hope that no one was so confused by reading his article that
they can't get unconfused. I strongly recommend reading ``A Shared
View of Sharing: The Treaty of Orlando'' (in {\em Object-Oriented
Concepts, Databases, and Applications\/}) for a good explanation of
what inheritance and delegation have in common and how they differ.
joetwl@brunix (Ted "Theodore" (W) Leung) (10/13/89)
In article <6219@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes: <comments deleted> >object type? Barfo dude! Sure, a graduate student can "prove", that >"Inheritance IS Delagation" but is is obviously the inferior form of >the duality. I think that we need to be careful about what exactly we mean when we say 'delegation' and what we mean when we say 'inheritance'. When most people talk about inheritance, they mean the standard Smalltalk-80 inheritance, and this is not at all what is meant in the OOPSLA-87 paper. The concepts presented in the paper cover many of your concerns about modular sharing, and do not restrict sharing in the fashion which you are concerned about. >Lynn Stein would have met with alot of disagreement if that paper was >presented at OOPSLA '89. I'm willing to bet that many of the ideas which you heard about at OOPSLA-89 probably originated in Lynn's paper or because of the discussions between her, David Ungar and Henry Lieberman. There are some very interesting, powerful, and practical ideas, many of which are available in any object oriented systems, in the paper. Before you simply dismiss someone out of hand for being a graduate student, perhaps you should take a look at their work. -------------------------------------------------------------------- Internet/CSnet: twl@cs.brown.edu | Ted Leung BITNET: twl@BROWNCS.BITNET | Box 1910, Brown University UUCP: uunet!brunix!twl | Providence, RI 02912
UH2@PSUVM.BITNET (Lee Sailer) (10/13/89)
<6219@jpl-devvax.JPL.NASA.GOV> <17795@brunix.UUCP> As long as we are being careful about what "inheritance" and "delegation" really mean, let's be careful about "proved" and "the same", too. One can prove that all computations are equivalent to some Turing Machine, but it is still true that computations is some language, even BASIC, offer many advantages over TM's. Even if inheritance and delegation can be shown to be logically equivalent in some fundamental sense, one might be a better notation or representation than the other for some purposes.
hallett@pet3.uucp (Jeff Hallett x5163 ) (10/19/89)
In article <6219@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes: >In article <17653@brunix.UUCP> sdm@norton.UUCP (Scott Meyers) writes: >>In article <125984@sun.Eng.Sun.COM> grover%brahmand@Sun.COM (Vinod Grover) writes: >>Lynn Stein, a graduate student here at Brown, proved that delegation and >>inheritance are equivalent. Hence, inheritance is not a "special case" of >>delegation. For the proof, see her paper in the OOPSLA '87 Proceedings: >>"Delegation Is Inheritance." > >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. The relationships you discuss can be expressed in the form of a type of aggragation relations. Aggragation relations, in general, allow for an object to be composed of other objects. A relation of this type is generally used to express things like sets, dictionaries, bags, lists, stacks, etc that are composed of instances of the same class (or subclass). However, we find it useful to generalize to say that a class may have several aggragate relations to different classes. By using relations in this way, it is still possible for the composite class to have properties and respond to messages as a unit and then handle delegating method work to its components. Are we all using the same definition of "delegation"? Delegation of responsibility (as we have described it here) is a natural result of the object-oriented paradigm - let each object handle the information and properties given to members of its class. Used this way, then car does not have to know specific about car doors - its simply queries the car door when it needs to know something. Clearly delegation in this sense cannot be equated to inheritance. Delegation allows for specificity of function and information whereas inhertitance allows for specificity of form - two related but not synonymous concepts. > >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 Did you just pull this out of your hat? I've never seen an inhertiance tree for a reasonably sized project with a depth less than 5. Object number is large, as you say, but for a complex system, it is EASY to have specialized needs that drive the tree to have long branches. -- Jeffrey A. Hallett, PET Software Engineering GE Medical Systems, W641, PO Box 414, Milwaukee, WI 53201 (414) 548-5163 : EMAIL - hallett@gemed.ge.com "Your logic was impeccable Captain. We are in grave danger."