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:
