Re: passing a method name?
Re: passing a method name?
- Subject: Re: passing a method name?
- From: Graham Cox <email@hidden>
- Date: Mon, 21 Dec 2009 10:29:02 +1100
On 21/12/2009, at 5:05 AM, Jeffrey Oleander wrote:
> OTOH
[]
> An action is the message a control sends to the target
Target/action is not what I was talking about at all. It's OK to store a SEL which is invoked as a response - the signature of that SEL does not change the behaviour or state of the control that invokes it.
What I took the OP to mean, and what I consider bad practice, is something like this:
- (void) someMethodCalledBy:(SEL) caller
{
if( caller == firstCaller )
DoAction1();
else
DoAction2();
}
that is quite different from simply invoking a SEL that you are passed:
- (void) someMethodWithCompletionMethod:(SEL) completion target:(id) target
{
DoAction1();
DoAction2();
objc_msg_send( target, completion );
}
Note that in the second case you also need a target - a "naked" SEL is not much use unless it has a target, either passed explicitly or implied. The first example is bad because its behaviour can't be predicted without knowing where it is called from, so it cannot be analysed or debugged in isolation.
> Not everyone would agree. I've written a professional application
> ("professional" meaning I was paid for it and it was used in an enterprise
> situation) that depended on this, and it never bit me, hard or otherwise.
> Certain aspects of the framework (for example, the way sheets work), and the
> dynamism of Objective-C messaging (for example, you can construct the name
> of the method to be called, in real time, based on the name of another
> method, and then call it), sometimes make this a very sensible way to
> implement a state machine. m.
This is still a different thing. Deciding on which method to call dynamically is fine, as long as the method called does not depend further on where it was called from. What you're basically talking about here is table-based dispatch, which is of course the fundamental mechanism for all object-oriented languages. I think what the OP was talking about was making a called method sensitive to its caller, which is a no-no.
Sheets require a completion method but the sheet itself will not behave differently according to that method - it simply invokes it when it's done. Completion methods and callbacks are also fine, because they do not change the state of the method they are passed to.
--Graham
_______________________________________________
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