Re: NSTimer: Debug vs. Release build
Re: NSTimer: Debug vs. Release build
- Subject: Re: NSTimer: Debug vs. Release build
- From: Michael Ash <email@hidden>
- Date: Mon, 16 Mar 2009 23:08:07 -0400
On Mon, Mar 16, 2009 at 8:34 PM, Martin Wierschin <email@hidden> wrote:
>>> btw, this method doesn't have any parameter, it's definition is:
>>
>> Whether you need it or not, you must take it, because that's the method
>> signature that NSTimer expects to call back.
>
> I don't want to confuse the issue for Stefan, as matching up selector/method
> names exactly is obviously very important. However, is there actually any
> issue when a dynamic method dispatch includes arguments not present in the
> actual method declaration/definition?
Theoretically speaking, it *could* certainly break. There is no
guarantee that things will work if the caller and callee disagree
about the number or type of arguments. For example, you could have an
ABI where the caller is responsible for setting up the stack but the
callee is responsible for tearing it down, and tearing it down
requires knowing the total size of the arguments.
Realistically, this works on every existing platform where OS X runs,
and on every platform where OS X would conceivably run. To
additionally support this, it would be very difficult to support the
existing semantics of a message to nil (returns 0 and otherwise does
nothing) without an environment that allows argument mismatches in
general. Furthermore, a lot of existing code passes no-argument
selectors to places where an argument is expected, and such a change
would break all of that. Lastly, many Apple methods which take a
selector and an argument explicitly allow you to use a selector which
takes no arguments, such as performSelectorOnMainThread:.
In conclusion, feel free to pass around selectors which take no
arguments even when they will be invoked with an argument.
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