Re: Interrogating selectors at runtime
Re: Interrogating selectors at runtime
- Subject: Re: Interrogating selectors at runtime
- From: Greg Herlihy <email@hidden>
- Date: Sun, 05 Feb 2006 20:58:15 -0800
- Thread-topic: Interrogating selectors at runtime
On 2/5/06 3:58 PM, "Andrew White" <email@hidden> wrote:
>
> Given a data entry of type SEL, is there an easy way to find out how many
> arguments it expects at runtime?
>
> Obviously, I can go NSStringFromSelector (aSelector) and then count the
> number of ':' characters, but that's expensive and clunky. Is there a
> better way?
Not really. And I don't see what good it would do to know the number of
arguments that need to be passed to a routine, unless one also knows their
types.
>
> A related question: what happens if I call 'performSelector:withObject' on
> a selector that takes no arguments, or
> 'performSelector:withObject:withObject' on a selector that takes only one?
> Are the surplus arguments harmlessly discarded?
The surplus arguments may well be "discarded". But I would be more worried
about the arguments that weren't. Calling functions blindly with arguments
of arbitrary number and type is not a recommended practice.
> eg:
>
> SEL aSelector = @selector (myMethod:)
>
> [aClassInstance performSelector: aSelector
> withObject: anObject
> withObject: anotherObject
> ];
>
> Will this harmlessly perform [aClassInstance myMethod: anObject] or will
> errors result?
What is the application expecting myMethod to do with anObject and
anotherObject? Clearly the app is passing anotherObject for a reason, and if
myMethod ignores anotherObject, then the app's reason for calling this
routine cannot be correct; essentially, the code at this point no longer
knows what it is doing.
If you are interested in packaging function calls, I would look at
NSInvocation - a class which essentially freeze-dries a method call. It will
wrap up the parameters and the selector into a nice tidy form that can be
subsequently invoked or itself be passed on as a parameter.
Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden