Path: utzoo!attcan!uunet!lll-winken!unixhub!shelby!neon!pescadero.Stanford.EDU!philip From: philip@pescadero.Stanford.EDU (Philip Machanick) Newsgroups: comp.object Subject: Re: ??Bidirectional Inheritence?? Message-ID: <1990Oct15.182357.2450@Neon.Stanford.EDU> Date: 15 Oct 90 18:23:57 GMT References: <6957@uwm.edu> Sender: news@Neon.Stanford.EDU (USENET News System) Reply-To: philip@pescadero.stanford.edu Distribution: comp Organization: Computer Science Department, Stanford University Lines: 28 In article , 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