Re: Using non-id sender in IBAction methods
Re: Using non-id sender in IBAction methods
- Subject: Re: Using non-id sender in IBAction methods
- From: Bryan Henry <email@hidden>
- Date: Sun, 07 Jun 2009 18:09:59 -0700
I hope you aren't suggesting that he use assertions in production code
- that's much worse practice than specifying a non-id parameter for an
action method.
As someone already said, if your action method is specific enough to
the type of sender object where specifying it's type keeps you from
casting, it's unlikely that you're going to have sender objects of
different types.
- Bryan
Sent from my iPhone
On Jun 7, 2009, at 4:05 PM, Uli Kusterer
<email@hidden> wrote:
Am 07.06.2009 um 08:45 schrieb Marc Liyanage:
With the new dot notation I sometimes use explicit types in my
IBAction methods:
- (IBAction)doSomething:(UIButton *)button ...
instead of
- (IBAction)doSomething:(id)sender ...
so I don't have to downcast "sender" to be able to use the dot
notation.
Do others do this too? Is this discouraged for some reason?
Not a good idea. The sender can be pretty much any object. It might
not be right now, but IBActions are often hooked up to several
objects, like a toolbar item, a pushbutton and a menu item. Hence
the definition as "id". By leaving it as "id" and then typecasting,
the assumption becomes explicit in the code. By having it as another
type right away, you're kind of masking the issue.
I recommend you write it as:
-(IBAction) doSomething: (id)sender
{
NSAssert( [sender isKindOfClass: [UIButton class]] );
UIButton* senderBtn = (UIButton*)sender;
// use btn here...
}
Or at least put an assert in there if you feel you need an IBAction
with a non-ID parameter type. The details of the assert are not as
important. In fact, if you can, use [sender respondsToSelector:
@selector(whateverYouAreCalling:)] or so instead of -isKindOfClass:.
The point of the assert is to make your code fail in a noticeable
way when someone breaks the assumptions it makes.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
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
_______________________________________________
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