ftp.nice.ch/peanuts/GeneralData/Usenet/news/1989/CSN-89.tar.gz#/comp-sys-next/1989/Oct/Multiple-inheritance-in-Objective-C?

This is Multiple-inheritance-in-Objective-C? in view mode; [Up]


Date: Sun 04-Oct-1989 02:45:48 From: Unknown Subject: Multiple inheritance in Objective-C? Are there any plans (at Stepstone, NeXT, or anywhere else for that matter) to add multiple inheritance to Objective-C? Single inheritance makes it unnecessarily difficult to modify the behavior of non-leaf classes of the AppKit. For example, suppose I make a subclass of Window, called MyWindow, which changes the behavior of one of the methods. Oh, let's say, the way the miniwindow's title is computed. Now, all I have to do is use instances of MyWindow instead of Window, and I get the new behavior. But... Panel is subclassed from Window, not MyWindow, so I have to go in and add or override those same methods in MyPanel. With two copies of the same code, sitting in two different classes, it's harder to maintain it. It would have been so nice to be able to do: @interface MyPanel: Panel, MyWindow { ... } Yes, I am aware of +poseAs:, but I'd only use it as last resort, maybe to make a last minute modification to a class system that is already designed and integrated. Or to experiment. But I'd much rather use class names explicitly, so that when you look at my program and read theWindow = [Window new] you know that theWindow will be a Window and not some other class. Another example of where I'd use multiple inheritance is to add or change functionality in a whole group of classes. For example, suppose I need a feature that flips a view horizontally before it's displayed (i.e., x coordinates grow to the left instead of to the right). In my application, I may use Boxes and Sliders that are flippable. All I need to do then is something like this: @interface FlippableBox : Box, Flippable { ... } @interface FlippableSlider : Slider, Flippable { ... } With single inheritance, I'm forced to either again duplicate code, or find the closest common ancestor of my Flippable classes (in this case, View), add the "flippability" code to its subclass (FlippableView), and then use +poseAs: to replace View with this subclass ([FlippableView poseAs:[View class]]). And while the +poseAs: solution may not be suitable if the are other descendants of the common ancestor (say, TextField) that will break due to the new code. Jacob
Date: Sun 11-Oct-1989 01:42:15 From: Unknown Subject: Re: Multiple inheritance in Objective-C? In article <130023@gore.com> jacob@gore.com (Jacob Gore) writes: >Single inheritance makes it unnecessarily difficult to modify the behavior >of non-leaf classes of the AppKit. For example, suppose I make a subclass >of Window, called MyWindow, which changes the behavior of one of the >methods. Oh, let's say, the way the miniwindow's title is computed. >Now, all I have to do is use instances of MyWindow instead of Window, and I >get the new behavior. > >But... Panel is subclassed from Window, not MyWindow, so I have to go in >and add or override those same methods in MyPanel. With two copies of the >same code, sitting in two different classes, it's harder to maintain it. >It would have been so nice to be able to do: > @interface MyPanel: Panel, MyWindow { ... } The way to do this would be to create a class, ComputeableName, witch is then added to both Panel and Window using MI. ComputeableName is an example of what is called a "mix-in", isolating an option that can be added to other classes. See Bobrow&Stefik (OO Programming: Themes and Variations, AI magazine, 1985) for a good treatment of this (and many other topics)). Using MI takes a good deal of care, but using "mix-ins" on predefined classes is manageable and also makes some sense in terms of "models of the real world". And, uhh, this really does not belong in comp.sys.next. Follow up to comp.object (no comp.lang.obj-c, yet). /Lars

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.