On Wed, Sep 10, 2008 at 11:36 AM, Ken Thomases <[EMAIL PROTECTED]> wrote: > On Sep 10, 2008, at 10:24 AM, Michael Ash wrote: > >> On Wed, Sep 10, 2008 at 11:13 AM, Ken Thomases <[EMAIL PROTECTED]> >> wrote: >>> >>> On Sep 10, 2008, at 9:52 AM, Michael Ash wrote: >>> >>>> And lastly, I recommend filing a bug against the documentation in this >>>> case. NSInvocation is not really suited for this particular task, and >>>> I don't understand why they would recommend it here. >>> >>> One possible reason is for proxying or otherwise handling unimplemented >>> methods dynamically. There is a well-defined mechanism for what happens >>> if >>> you send a message to an object that doesn't directly implement a method >>> for >>> that message. A class can decide to forward the message, or it can do >>> something funky in an override of doesNotRecognizeSelector:. That >>> mechanism >>> does kick in for performSelector:… and NSInvocation but doesn't for >>> methodForSelector:. >> >> Works fine for me: > > Interesting. I guess I was misled by the part of the methodForSelector: > documentation where it suggests using respondsToSelector: to test if the > selector is "valid". > > Never mind. ;)
Don't feel too bad. You made a convincing case, which is why I wrote code to see what would actually happen. I'm not really sure why the documentation has that note. After all, wouldn't the same be true of any way of sending a message? And in case anybody is wondering how the heck this works when the method isn't implemented, it's actually pretty straightforward. Cocoa has an internal function which builds an NSInvocation from the method arguments, then calls -forwardInvocation: with that newly-built object. In the case of an unimplemented selector, -methodForSelector: essentially just returns a pointer to that special function. So all unimplemented selectors will always return the same function. (Or, probably, it will return one of a couple of different functions depending on the calling convention required for the method's return type.) And lastly, for the sake of completeness, I'll also mention that you can achieve this goal by directly calling objc_msgSend, or one of its friends, depending again on the calling conventions required. I discourage this, simply because you need to know which one of its friends you need based on the return value (and it can change when you move to a new architecture, as we all discovered when Intel OS X introduced objc_msgSend_fpret) whereas with -methodForSelector: you don't. But it's faster for a single call,and can be handy to know about. Mike
_______________________________________________ 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 [EMAIL PROTECTED]
