Re: respondsToSelector - #import OR compiler warnings?
Re: respondsToSelector - #import OR compiler warnings?
- Subject: Re: respondsToSelector - #import OR compiler warnings?
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 30 Dec 2008 10:07:58 -0800
On Dec 30, 2008, at 9:50 AM, Steve Cronin wrote:
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?
As noted in my original post, the pattern I demonstrated was directly
derived from the delegation pattern in the AppKit.
Note that there is *no* implementation. It is just a declaration.
Thus, there is no risk of a 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.
If you have to use -performSelector: (or one of its variants) to avoid
a compiler warning, you are doing it wrong.
(Notice how Bill's example appears to presume this 'easy' use of -
performSelector()!)
It presumes no such thing.
The whole point of declaring the methods is so that you can invoke the
code using normal method invocation syntax without the compiler
complaining:
[bob foo2: fred];
b.bum
_______________________________________________
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