Re: NSInvocation
Re: NSInvocation
- Subject: Re: NSInvocation
- From: "Michael Ash" <email@hidden>
- Date: Wed, 10 Sep 2008 13:03:47 -0400
On Wed, Sep 10, 2008 at 11:36 AM, Ken Thomases <email@hidden> wrote:
> On Sep 10, 2008, at 10:24 AM, Michael Ash wrote:
>
>> On Wed, Sep 10, 2008 at 11:13 AM, Ken Thomases <email@hidden>
>> 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 (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