jacob@gore.com (Jacob Gore) (10/04/89)
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
--
Jacob Gore Jacob@Gore.Com boulder!gore!jacobfischer@iesd.auc.dk (Lars P. Fischer) (10/11/89)
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 -- Copyright 1989 Lars Fischer; you can redistribute only if your recipients can. Lars Fischer, fischer@iesd.auc.dk, {...}!mcvax!iesd!fischer Department of Computer Science, University of Aalborg, DENMARK. "That makes 100 errors; please try again" --TeX