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: email@hidden
- Date: Fri, 18 Apr 2008 10:56:08 +0200
On 18 Apr 2008, at 06:20, Adam P Jenkins wrote:
Of course (and as you have discovered), there are an awful lot of
situations where a 'nil' return value is actually indicative of a
serious problem -- something has failed that shouldn't have. And
tracking it down can be a pain.
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.
Just invert the assumption: when you do care about things not being
nil, encapsulate it in an "if" statement, otherwise don't bother. And
document when a nil return value indicates a problem! IMHO this
creates more readable code then the other way around. The examples of
a possible dealloc implementation are trivial but to the point.
Like Mr. Bumgarner said it is all a matter of opinion. I always
assumed the designers of the Objective-C language and Cocoa frameworks
trust me to know what I'm doing while I find very elegant ways to
shoot myself in the foot. I prefer this to a language and environment
that treats me like a grunt and doesn't trust me every step of the way
and I just end up with no hair left on my head.
Annard
_______________________________________________
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