OOP and Foundation 5: Multiple inheritance
OOP and Foundation 5: Multiple inheritance
- Subject: OOP and Foundation 5: Multiple inheritance
- From: Michael Gersten <email@hidden>
- Date: Mon, 10 Jun 2002 13:48:51 -0700
This is part five.
A way to implement multiple inheritence.
A way to use Protocol Checkers to implement truly private methods.
Last time, I had mentioned the desirability of a protocol for each class definition, generated automatically.
>
> What does this give you? If you have a new class, relatively unrelated to
>
> an existing class, but with one of those old class members as an ivar,
>
> you could give a compiler directive to say "Anything I didn't mention of
>
> protocol classFooProtocol that is sent to me is forwarded to ivar myFoo".
>
> Then, you can have an NSView as an ivar, make sure that it always stays
>
> offscreen, never becomes first responder, and use your class exactly as
>
> an NSView for drawing, even though you are completely unrelated. Call it
>
> "MyOffscreenBitmap", or something like that. Completely unrelated to
>
> NSView _codewise_; fully equivalent for drawing into it and giving it to
>
> other routines that work with NSView.
>
>
Objective-C was explicitly designed as a light weight fully dynamic OO
>
language. This runs counter to the design goals of the language.
>
Furthermore, ObjC was designed without multiple inheritance for the sake
>
of simplicity and compactness.
Here I was misunderstood.
I believe that Appkit already has such a class, that does use an offscreen window as an ivar to do this. If not, then yes, it's trivial to add. Again, this was just an example.
Nor is it even something that requires a change to the run-time. I can easily think of a class that provides multiple inheritance by using this.
Call this class "cover". Give it two ivars, and a way to set them.
Now, determine what the meta functions of <NSObject> are. Override these.
The basic function of this class is to say "I just got a message. I don't implement anything, but I can forward this message to my instance variables, while inside a handler. If the first one raises, I can catch it, and use the second instance variable instead".
The meta functions? Things like "What is the class of this object" (class, isKindOfClass, ...), archiving, etc.
[Note that it isn't necessarily clear what the proper override is for all of these. You can imagine subclasses of Cover that have different ideas on how to override them.]
Such a class can implement multiple inheritance by having multiple parent objects, without requiring strict compiler class tree layout. By having multiple cover objects, you can have n-object inheritance, not just two. [Heck, one subclass might take an array of these things, or it might become a cluster of classes.]
A subclass of this could actually do things, and, by leaving one of it's forwarding ivars blank, implement the "Anything I don't explicitly say, forward to this guy". Suddenly, I can support the idea of that "I'm not really a view, I never go onscreen, but you can still draw to me and dump me to a file" class. Even if the class I'm pretending to be is extended.
Or, you could keep Cover as a seperate root, with no real classes, and have the first ivar for the main (warrior) class, and the second ivar for the supplemental (diplomat) class.
An example: a warrior that knows how to behave like a diplomat. Even if you don't know everything that a diplomat does, you can still behave like one when necessary. Even if, when your code is written, all a diplomat knows is "negotiate", you will still act like a diplomat if they are later taught "agressiveNegotiate". Depending on which subclass of Cover you are using, that last call could use the warrior version of "fight" instead of the diplomat version.
Now, you could go a step further. You could put a protocol checker on one of those ivars, and limit it to to declared public methods of the class. But if I did that myself, I'd have to stick a compile-time protocol on, and then it would be fixed. Even if the public declared methods of the emulated class are expanded, my protocol is already there.
The solution? Class protocols, described in part 4.
>
b.bum
>
....lying there snoring,
>
breath smelling like a 1948 buick.
--
I am a Mac 10-Cocoa/WOF/EOF developer, and I'm available for hire. Please contact me at michael-job @ stb.nccom.com if interested. Resume at
http://resumes.dice.com/keybounce
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.