Re: Multiple Inheritence (Was: Is _objc_flush_caches_(Class) necessary to swizzle methods?)
Re: Multiple Inheritence (Was: Is _objc_flush_caches_(Class) necessary to swizzle methods?)
- Subject: Re: Multiple Inheritence (Was: Is _objc_flush_caches_(Class) necessary to swizzle methods?)
- From: DumberThanDanQuayle <email@hidden>
- Date: Sat, 25 Sep 2004 08:40:43 -0400
Tor, thanks for your input.
What you are suggesting sounds similar to what Glenn Andreas purposed.
Indeed this pattern appears to be is built into to Cocoa with the
[NSObject forwardInvocation] system. I admit this is something I have
to yet to explore in any depth. But this does not match the pattern
that I am using. I have classes on different branches of my object
family that are so similar that their entire implementations are
identical. Yet they need to be distinct for good reasons like some
calls to "super" spawn threads to execute while other do not. I mean I
have a set of "master" and "slave" type classes that form a inheritance
but otherwise implement the same protocols. In other cases, classes
are identical down to "dealloc" but a have few a unique methods.
So far, which is less than a day, I am very happy with the solution I
came up with as describe in detail in my previous posts. This is
simply using the C preprocessor "#include" macro to "paste" in method
implementations. Now, the only redundancy is in the complied code.
While I might prefer some formal Obj-C mechanism to do this that would
also eliminate redundant complied, it is certainly is not necessary.
Using the "include" seems like an idiot-proof way to do weak multiple
inheritance with protocols and is really no more objectionable than
using "#import" to redundantly insert headers into a compilation. So
far the only down side looks like the compilation errors and warnings
are not marked directly on the methods included but rather at the
"#import" directive. Likewise, there may be problems with the debugger
indicating which line is executing or crashed, but I have yet to test
that issue. Furthermore, while I would rather have some formal
mechanism to deal with those issues, I can easily live with them or
work around them by temporarily placing my method implementations into
a proper class.
Yours, George.
On Sep 25, 2004, at 7:52 AM, Tor Manders wrote:
George,
perhaps the pattern you are looking for is a separate class with the
methods you want defined there (perhaps as class methods). these
methods can be invoked as
[SharedProcessingClass doSomeSharedMethodOn: self];
of course, all of the various 'self's will need to conform to some
(ideally formal) protocol so that you can polymorphically interact
with them.
then, in each of your classes, you can write a wrapper around the call
like so...
- (ReturnType) doSomething : (AType) parameter {
...
[SharedProcessingClass doSomeSharedMethodOn: self];
...
return something;
}
Tor Manders
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden