Re: Multiple Inheritance (not Marathon Infinity)
Re: Multiple Inheritance (not Marathon Infinity)
- Subject: Re: Multiple Inheritance (not Marathon Infinity)
- From: Greg Titus <email@hidden>
- Date: Wed, 5 Dec 2001 17:34:01 -0800
On Wednesday, December 5, 2001, at 04:23 PM, Rosyna wrote:
If I have this right, Multiple Inheritance is the ability for a class
to inherit from multiple parent classes that do not necessary inherit
or derive from eachother. Like iostream.h inherits from istream and
ostream. Is this correct?
If this is correct, I present something.
Since Objective C does not support MI, doesn't this cause problems with
things like NSTextField? It's parents (Path: :NSControl : NSView :
NSResponder : NSObject) never inherit from NSText. So, as a
workaround we have a/an -(id)cell method in NSControl which returns an
instance of some NSText child class that has been initialized. Is this
correct?
First of all, no, that's not the way the text system works.
NSText (and friends, like the layout manager, type setter, text storage,
et cetera) is a pretty heavyweight set of objects. So all text fields in
a window share a single NSText object called the field editor. When you
edit a text field, the field gets the field editor, puts its text into
it, and places it on top of its own view. From then on you are
interacting with that one NSText object, not the text field at all. So
the text field is essentially 'static'. The field editor is where you do
all the changing. When you are done, the text field gets the text back
out of the field editor and statically displays it again.
This design decision was made to reduce the overhead of having many text
views when you really only need one. I don't think it had anything to do
with multiple inheritance or the lack thereof.
Similarly, the distinction between NSControls (which are views) and
NSCells (which are not) have to do with how heavyweight views are
(relatively). In most controls there is one cell to each view (i.e.
buttons, text fields, etc), but it makes a big difference in NSMatrix
and NSBrowser to not have all of the overhead of a full view. (Remember
that views need to support things like rotation, scaling, clipping, et
cetera.)
(I should also note that both these design decisions date back to
NeXTStep, where you were talking about 68030's with 8 megs RAM at the
low end. But they still seem like good tradeoffs to me.)
This seems to lead to some redundantly declared methods in each class
and some confusion about how to access some properties of NSTextField.
Would not this specific "problem" be "fixed" if MI existed in
Objective-C?
A similar case can be made for some other classes. But I think
NSTextField illustrates it best.
I think your example kind of falls apart because you didn't understand
how NSTextField and NSText are actually related...
(Which, as an aside, should really be documented better. There are a
couple FAQs on this list that are derived from misunderstanding the
relationship.)
Hope this helps,
--Greg