RE: Cocoa and messages to nil, revisited
RE: Cocoa and messages to nil, revisited
- Subject: RE: Cocoa and messages to nil, revisited
- From: Jeff Laing <email@hidden>
- Date: Wed, 8 Aug 2007 16:18:55 +1000
> Doesn't matter. Sending messages to nil is easier to read and well
> established as generally safe in Cocoa. The areas where it is unsafe
> are well documented. I enjoy sending messages to nil. Obviously so
> does much of Apple, and I'm sure much of the rest of the Cocoa
> developer world.
No argument that
[something release];
might seem easier to read than
if (something) [something release];
but thats the trivial case. This thread started from a discussion of
[something with:[somethingelse using:[thirdthing blah]]];
where somethingelse was *accidentally* nil. The point being that it becomes
a nightmare to try to FIND that sort of problem since Cocoa gives you no
help at all, despite Objective-C actually having a hook that *could* help if
Cocoa were a bit tidier.
The problem here is not that sending message to nil is unsafe. Its that in
buggy code, sending message to nil is *not what you thought you were doing*,
and the mechanism that Objective-C provides to catch it is deliberately
obfuscated by Cocoa design tendencies, which are (in my opinion) lazy.
C++ has the same lazy notion, in exactly one case. "delete NULL;" will
silently work. ANSI C has the same. "free(NULL)" will silently work. In no
other case will a nil-pointer-dereference work because in no other case
should a programmer being doing such a thing. And I contend that in Cocoa,
the only similiarity is release. I don't care if I send release to nil, but
I would really like to know why NSMenu sends it copyWithZone: (for example),
not to mention why Cocoa keeps sending it isKindOfClass:
I don't want to discuss this in terms of language. Its not an Objective-C
issue, its a Cocoa issue, a style problem. In fact, I don't really want to
discuss it at all because very few people will consider it objectively
(sic). I *know* where I have had problems developing with the Cocoa
frameworks, and a large number of those problems were because message to nil
could not be detected without tedious "debug-by-printf" insertion of NSLog()
statements, which is ludicrous. All for the benefit of the lazy programmer
who didn't want to put 'if(ptr)' in front of messages to objects that might
not be there.
_______________________________________________
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