On Apr 17, 2008, at 5:42 PM, Adam P Jenkins wrote:
I'm curious if anyone knows the rationale behind the decision to
make sending messages to nil be a no-op in ObjC. I've used a
number of other OO languages, including C++, Java, Python, Ruby,
Smalltalk, and Javascript, and in all of them, trying to invoke a
method on whatever their equivalent of nil is produces a runtime
error of some sort. In practice, I've found Obj-C's practice of
ignoring method calls to nil to be just annoying, since it masks
bugs unless you turn on NSZombiesEnabled. I can imagine that
sometimes it would be convenient to have some kind of message sink
which just accepts and ignores all messages, but why not just have a
special NSSink class for that instead of making nil behave that way?
I know there's no chance of this feature of the language changing at
this point. I'm just wondering if there's some good rationale for
it that I'm not thinking of. Thanks,
(1) And many Java programmers find the constant need to check for
nulls or null pointer exceptions to be ugly and inconvenient....
Without expressing my personal opinion, there is no "right" answer...
only very strongly held opinions.
Like Java provides NullPointerExceptions to provide a fairly
convenient debugging hook for messages to nil, Objective-C offers a
set of hooks for tracking down messages to nil. I wrote some up here:
http://www.friday.com/bbum/2008/01/02/objective-c-logging-messages-to-nil/
http://www.friday.com/bbum/2008/01/03/objective-c-using-dtrace-to-trace-messages-to-nil/
http://www.friday.com/bbum/2008/01/04/objective-c-using-instruments-to-trace-messages-to-nil/
(2) NSZombiesEnabled has absolutely nothing to do with messages to
nil. NSZombiesEnabled is for figuring out what objects have been
over released or where you might have a stray pointer to an object
that has already been released.
(3) Some history:
When NeXTSTEP was originally designed (mid '80s), the APIs generally
followed a pattern of always returning self. That is, instead of:
- (void)setFrameOrigin:(NSPoint)newOrigin;
- (void)setFrameRotation:(float)angle;
- (void)removeAllObjects;
- (void)setArray:(NSArray *)otherArray;
It would follow this pattern:
- setFrameOrigin:(NSPoint)newOrigin;
- setFrameRotation:(float)angle;
- removeAllObjects;
- setArray:(NSArray *)otherArray;
And, thus, you would commonly see code in chained form:
[[[aView setFrameOrigin: p] setFrameRotation: 42.0] setNeedsDisplay:
YES];
Or, in some cases, even longer. Now, if a 'nil' were produced by any
of the sub-expressions, not having nil-eats-message behavior would
mean that an exception would be raised in a spot where there was no
convenient means of figuring out what is going on. Not having nil-
eats-message meant that such chains could be written without worry.
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.
------
Read on for why the pattern of the API changed (mostly)....
About the same time that OpenStep was being designed as a derivative
standard of the NeXTSTEP APIs (early 90s), Distributed Objects was
rolled out.
Distributed Objects, as you likely know, is all about allowing objects
in potentially widely separated -- as in, thousands of miles and
potentially slow, highly latent, connections between -- runtimes to
invoke methods on each other as if they were local.
Now, since the methods are being invoked in some other runtime, it is
obviously highly desirable to invoke the methods in an asynchronous
manner. But if the method being invoked returns something, it can't
be asynchronous because the caller has to wait around until the return
value comes back across the wire!
So, OpenStep moved to the standard pattern of returning (void)
whenever a method does not need to return some specific result.
b.bum
_______________________________________________
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]
