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 (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 [EMAIL PROTECTED]
