Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!swrinde!ucsd!dog.ee.lbl.gov!nosc!crash!nkraft From: nkraft@crash.cts.com (Norman Kraft) Newsgroups: comp.object Subject: Re: ??Bidirectional Inheritence?? Message-ID: <5070@crash.cts.com> Date: 16 Oct 90 15:31:46 GMT References: <6957@uwm.edu> <1990Oct15.182357.2450@Neon.Stanford.EDU> Distribution: comp Organization: Crash TimeSharing, El Cajon, CA Lines: 37 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... --------------------------------------------------------------------------