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 (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 arch...@mail-archive.com

Reply via email to