Re: Why is [nil aMessage] a no-op?
Re: Why is [nil aMessage] a no-op?
- Subject: Re: Why is [nil aMessage] a no-op?
- From: "Gerriet M. Denkmann" <email@hidden>
- Date: Fri, 18 Apr 2008 10:32:24 +0200
On 18 Apr 2008, at 07:18, email@hidden wrote:
Date: Fri, 18 Apr 2008 00:56:13 -0400
On Apr 18, 2008, at 12:47 AM, Bill Bumgarner wrote:
On Apr 17, 2008, at 11:20 PM, Adam P Jenkins wrote:
Exactly. And now that the convention of methods returning self no
longer exists, it seems like there's no longer any advantage to
this behavior.
There are 10s of thousands invocations of methods on nil objects
during the normal, non-error-path, execution of your average Cocoa
application that indicate that this behavior is still, very much,
used to the advantage (where 'advantage == convenience') of Cocoa
programmers.
Can you give an example of where invoking methods on nil objects would
make sense in a non-error-path situation? I'm not trying to be
argumentative here, I'm really curious to know what Objective-C idioms
take advantage of the nil-swallows-messages behavior. Thank you.
if ( [myContainer count] == 0)
{
// myContainer does not exist, or is empty. In both cases there is
nothing for us to do.
return;
}
// do something with the things in myContainer...
if ([myObject isValid])
{
// do something with myObject
}
else
{
// no myObject or an invalid one. Do nothing.
}
Kind regards,
Gerriet.
_______________________________________________
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