ctumey@csd4.csd.uwm.edu (Carol T Tumey) (10/15/90)
Recently I was involved in a conversation discussing the various possiblities of handling inheritance in a multiple inheritance system. Out of the discussion came the topic of bidirectional inheritence. The person who suggested this claimed that the concept of parents inheriting back from their children is a proven idea yet could provide no references. In the small amount of reading I have done on OOP/OOD I have not seen anything on the subject of parents inheriting values from their children nor can I see the benfits of such hierarchical incest :-) Seriously, it seeems that inheriting characteristic up *and* down the network would result in a loss of control of the system and defeats some of the basic concepts of OOP such as encapsulation, not to mention inheritence. Does anyone have any opinions either way on the subject? I would be interested in your replies. Thanks, Carol Tumey ctumey@csd4.csd.uwm.edu
davidm@uunet.UU.NET (David S. Masterson) (10/15/90)
In article <6957@uwm.edu> ctumey@csd4.csd.uwm.edu (Carol T Tumey) writes:
Seriously, it seeems that inheriting characteristic up *and*
down the network would result in a loss of control of the
system and defeats some of the basic concepts of OOP such as
encapsulation, not to mention inheritence.
If you think about, is this not the end result of virtual functions in C++?
Through pure virtual functions, it becomes possible to ask an instance of a
parent class object something about its child (like asking the object what its
type is).
--
====================================================================
David Masterson Consilium, Inc.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"philip@pescadero.Stanford.EDU (Philip Machanick) (10/16/90)
In article <CIMSHOP!DAVIDM.90Oct14231135@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: |> In article <6957@uwm.edu> ctumey@csd4.csd.uwm.edu (Carol T Tumey) writes: |> |> Seriously, it seeems that inheriting characteristic up *and* |> down the network would result in a loss of control of the |> system and defeats some of the basic concepts of OOP such as |> encapsulation, not to mention inheritence. |> |> If you think about, is this not the end result of virtual functions in C++? |> Through pure virtual functions, it becomes possible to ask an instance of a |> parent class object something about its child (like asking the object what its |> type is). In Smalltalk, too, self refers to the current object, not the current class, so a parent can refer to the child's method by invoking through self. This however is not the same thing as changing the parent's behaviour by adding "reverse-inheritance". I have seen this feature explicitly provided in an expert system shell called Nexpert. I can't say I liked the idea. Consider a classic example - window inherits from rectangle, and overrides draw, while leaving move the same. In rectangle, move is implmented using draw. If you ask a window to move itself, move asks the current object to draw itself, resulting in the expected behaviour. Of course, windows also do stuff that rectangles don't do (e.g., scroll), so the window class would introduce a method to scroll. If "reverse-inheritance" existed, you could pass this new behaviour up to rectangles (if this made sense). Looks like a recipe for unmanageable code to me... -- Philip Machanick philip@pescadero.stanford.edu
nkraft@crash.cts.com (Norman Kraft) (10/16/90)
In article <1990Oct15.182357.2450@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >In Smalltalk, too, self refers to the current object, not the current class, >so a parent can refer to the child's method by invoking through self. This >however is not the same thing as changing the parent's behaviour by adding >"reverse-inheritance". I have seen this feature explicitly provided in an >expert system shell called Nexpert. I can't say I liked the idea. Consider >a classic example - window inherits from rectangle, and overrides draw, while >leaving move the same. In rectangle, move is implmented using draw. If you >ask a window to move itself, move asks the current object to draw >itself, resulting in the expected behaviour. Of course, windows also do stuff >that rectangles don't do (e.g., scroll), so the window class would introduce >a method to scroll. If "reverse-inheritance" existed, you could pass this >new behaviour up to rectangles (if this made sense). Looks like a recipe for >unmanageable code to me... >-- >Philip Machanick >philip@pescadero.stanford.edu Well..... from a purist standpoint I certainly agree, but from a practical point of view I find some form of "reverse inheritance" to be somewhat useful at times. There are applications where it is desirable for an object to do something which can be interchangably provided by the various children, though one must indeed be careful with it. More to the point, though, people have been doing a primitive "reverse inheritance" for years with function pointers, and I suppose that will remain the answer for some time to come. At least it is here in our shop. -------------------------------------------------------------------------- Norman R. Kraft "Things should be as simple Director, Software Development as possible, but not simpler." Postal Buddy Corporation, San Diego, CA - Albert Einstein INET nkraft@crash.cts.com UUCP {hplabs!hp-sdd ucsd nosc}!crash!nkraft Usual disclaimer applies... --------------------------------------------------------------------------
jensen@skinfaxe.diku.dk (J|rgen Jensen) (10/21/90)
In some other connection I stumbled across something like this
yesterday. In the book "Readings in Artificial Intelligence
and Databases", edited by John Mylopolous and Michael Brodie
(ISBN 0-934613-53-2) there is a section 2.2.3 entitled "On the
design and Specification of Database Transactions, written by
Michael L. Brodie and Dzenan Ridjanovic.
Quotes:
[p. 187]
3. Structure Modelling
3.1 Extended Semantic Hierarchy Model (SHM+)
For the design and specification of structural properties of
database applications, SHM+ provides one structural concept, the
object, and four forms of data abstraction for relating objects:
Classification, aggregation, generalization, and association.
[...]
_Classification_ represents an _instance-of_ relationship between
and object class in a schema and an object in a database. [...]
[p. 188]
Aggregation and association support upward inheritance in which
properties of the componenents for members are inherited by the
aggregate or set. For example, the properties of the components
_employee-name_, _employee-number_, and _salary_ are inherited
as properties of the aggregate _employee_. Aggregates and sets
are designed by _decomposition_ into, or _composition_ from
components or members without concern for their properties.
Generalisation supports downwards inheritance in which all
properties of a generic object are inherited by each of its
category objects.
end quotes.
. . . . . . . . . . . . . . . . . . . . . . . . . . j e n s e n
(jensen@diku.dk)hjb@otter.hpl.hp.com (Harry Barman) (10/22/90)
A co-worker of mine (Claus Pedersen) published a paper in last year's OOPSLA about generalisation (upward inheritance) and specialisation (downward inheritance) of object *interfaces*. Claus H. Pedersen, "Extending Inheritance Schemes to Include Generalization", Proc. OOPSLA '89, pp. 407-417 Cheers, Harry
jep@mtiame.oz (Jesper Peterson) (10/23/90)
In article <6957@uwm.edu> ctumey@csd4.csd.uwm.edu (Carol T Tumey) writes: >[....] >In the small amount of reading I have done on OOP/OOD I have >not seen anything on the subject of parents inheriting >values from their children nor can I see the benfits of >such hierarchical incest :-) Do virtual functions in C++ qualify? (I'm asking) An example given in Bjarne Stroustrup's book is: [page 37] A "Shape" class which does not have the attributes required to sensibly respond ro a "draw" message. It does, however, declare the "draw" function as "virtual". Derive some classes from Shape, such as Circle, Square etc. Each of these properly define the "draw" function. You can now store a mixture of Circles and Squares in an array of Shapes. You can loop through this array and sensibly send "draw" messages to instances of Shape rather than the specialised classes. As I understand it, Shape effectively "inherits" "draw" from it's children. I'm new at OOP so speak slowly when you respond :-) Jesper. -- ACSnet: jep@mtiame.mtia.oz UUCP: ...!uunet!munnari!mtiame.oz!jep [...] I had to leave out reality to keep the post clean and to the point. - jeremy@milton.u.washington.edu (Jeremy York) in rec.music.misc
gordon@meaddata.com (Gordon Edwards) (10/23/90)
In article <304@mtiame.oz>, jep@mtiame.oz (Jesper Peterson) writes: |> In article <6957@uwm.edu> ctumey@csd4.csd.uwm.edu (Carol T Tumey) writes: |> >[....] |> >In the small amount of reading I have done on OOP/OOD I have |> >not seen anything on the subject of parents inheriting |> >values from their children nor can I see the benfits of |> >such hierarchical incest :-) |> |> Do virtual functions in C++ qualify? (I'm asking) |> An example given in Bjarne Stroustrup's book is: [page 37] |> A "Shape" class which does not have the attributes required to |> sensibly respond ro a "draw" message. It does, however, |> declare the "draw" function as "virtual". |> Derive some classes from Shape, such as Circle, Square etc. Each |> of these properly define the "draw" function. The word virtual tells the compiler that the function draw() should be bound at run-time. The default (no virtual keyword) binds the draw() function at compile time. |> You can now store a mixture of Circles and Squares in an array |> of Shapes. What you are describing here is a polymorphic array. The array of Shape& can store Shapes and Circles and Squares (which are also Shapes). |> You can loop through this array and sensibly send "draw" |> messages to instances of Shape rather than the specialised |> classes. If I have an instance X of Circle, then I also have an instance of Shape. When X calls draw(), the class definition of Circle is checked and if draw() exists X is bound to it. If not, the class definition of Shape is checked and if draw() exists, X is bound to it. This continues up the class hierarchy. |> |> As I understand it, Shape effectively "inherits" "draw" from it's children. |> Not really, Shape's draw is never examined. This is hard to explain without being able to talk face-to-face and draw pictures. Try to remember that the order of evaluation starts at the sub-class (or leaf) and works up through the class hierarchy. -- Gordon (gordon@meaddata.com)
schrefl@vexpert.dbai.tuwien.ac.at (Michael Schrefl) (10/25/90)
that is, creating a new superclass for existing classes and
factoring out attributes and methods common to the classes into the
superclass. Our paper
"Object class definition by generalization using upward
inheritance" (M. Schrefl, E.J. Neuhold)
IEEE 4th Int. Conf. on Data Engineering, pp. 4-13
addresses this problem.
Michael Schrefl
Vienna University of Technology