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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
