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: Bill Bumgarner <email@hidden>
- Date: Fri, 18 Apr 2008 00:46:30 -0500
On Apr 17, 2008, at 11:56 PM, Adam P Jenkins wrote:
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.
Keeping in mind that one must assume that convenient == correct in
this case, consider the following pseudo code:
// pseudo code, obviously... but you get the pattern.
NSView *targetView = [myWindow giveMeTargetViewForEvent: anEvent];
[targetView eatEvent: anEvent];
... etc ...
Real world:
If you run the dtrace script written up here:
http://www.friday.com/bbum/2008/01/03/objective-c-using-dtrace-to-trace-messages-to-nil/
(save the file as 'nil.d' and then modify the 'pid$1' to be 'pid
$target' and then use 'sudo dtrace -s nil.d -c /Applications/
TextEdit.app/Contents/MacOS/TextEdit')
You'll see many hundreds of cases where the AppKit and Foundation rely
upon nil-eats-message during the normal operation of a Cocoa
application.
Some likely scenarios:
1 19008 objc_msgSend:entry
libobjc.A.dylib`objc_msgSend
AppKit`-[NSMenuItem initWithCoder:]+0x74e
-initWithCoder: has some kind of decoding delegate or other object
that, if set, modifies the decoding. If not set, it does nothing.
1 19008 objc_msgSend:entry
libobjc.A.dylib`objc_msgSend
AppKit`FindUserKeyEquivalentString+0x9d
AppKit`-[NSMenuItem _cacheUserKeyEquivalentInfo]+0xa1
Nothing was found and the end result might have been [[nil retain]
autorelease].
1 19008 objc_msgSend:entry
libobjc.A.dylib`objc_msgSend
AppKit`-[NSView trackingAreas]+0xab
AppKit`-[NSView _setWindow:]+0x5ee
AppKit`-[NSControl _setWindow:]+0x65
Might be that no tracking areas exist or that the window is not key
and, thus, tracking areas is nil?
1 19008 objc_msgSend:entry
libobjc.A.dylib`objc_msgSend
AppKit`-[NSDocument dealloc]+0x1f5
TextEdit`0x9c91
Some instance variable of the NSDocument was never set or was already
set to nil. [ivar release] was really [nil release].
1 19008 objc_msgSend:entry
libobjc.A.dylib`objc_msgSend
AppKit`-[NSView removeFromSuperview]+0xb8
AppKit`-[NSView
removeFromSuperviewWithoutNeedingDisplay]+0x2e
The view might not have been in a superview in the first place during
some other generic display hierarchy manipulation.
1 19008 objc_msgSend:entry
libobjc.A.dylib`objc_msgSend
AppKit`-[NSView _convertRectToSuperview:]+0x67
AppKit`-[NSView _convertRect:toAncestor:]+0x5c
Might have hit nil during traversal of the view hierarchy.
You get the idea. I didn't look at the source of the appkit to know
definitively why any one of these messages-to-nil are expected. All
of these-- and hundreds more-- are messages-to-nil that occur during a
run of TextEdit -- launch app, click document window, close, quit.
Note that the nil-eats-message branch of objc_msgSend() is very cheap/
fast.
b.bum
(None of this is meant to be a statement about my personal opinion of
nil-eats-message. At this point, it is irrelevant. Cocoa has adopted
a particular pattern throughout its implementation and so have many
many developers, whether knowingly or not. It can't be changed
without breaking lots and lots of applications. That'd be weak sauce.)
_______________________________________________
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