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: Andy Lee <email@hidden>
- Date: Sun, 07 Jun 2009 21:34:42 -0400
On Jun 7, 2009, at 9:09 PM, Bryan Henry wrote:
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.
Well, you can configure your build to strip NSAssert from Release
code, if that isn't the default already. I assume Uli meant this as a
debugging aid.
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.
I never thought of trying this before, but it seems that having a more
narrowly defined sender also limits the kind of controls IB lets you
connect *from*, at least in the Cocoa IB and presumably in the iPhone
IB as well.
--Andy
- 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
_______________________________________________
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