Re: respondsToSelector - #import OR compiler warnings?
Re: respondsToSelector - #import OR compiler warnings?
- Subject: Re: respondsToSelector - #import OR compiler warnings?
- From: Steve Cronin <email@hidden>
- Date: Tue, 30 Dec 2008 11:50:21 -0600
Folks;
This is a clarification for the record
After some sleep and a cup of coffee and I realize that something I
wrote was hasty, oh OK, sloppy!
I took Bill's quoted example:
@interface NSObject
(MyClassOptionalMethodsThatMightBeImplementedByJustAboutAnything)
- (void) someSpecial: (Sauce *) aSauce;
- (BOOL) isBobYourUncle: (Child *) aChild;
@end
and morphed it to:
//respondsToSelector silencer - see -myMethodName
@interface NSObject (MyClassName)
- (id) foo;
@end
It now seems to me that while attaching my tweak to the header does in
fact silence the compiler, it is overly broad -> 'sloppy'.
Why create a category on the entire hierarchy of NSObject? Why create
the possibility (albeit remote) of category collision?
A more targeted solution is:
//subclass needs to provide for dynamic handlers
@interface MyClass (RespondsToSelector)
// see also usages of -performSelector()
- (id) foo2:(id)param;
@end
This solution, combined with Ken's proposal to use -performSelector
for the 'no parameters' cases, seems to give me a good solution.
(Notice how Bill's example appears to presume this 'easy' use of -
performSelector()!)
Hope this is useful to someone else...
Steve
NOTE: -performSelector() does have permutations that would make it
possible to not have the category declaration at all!
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden