On Wed, Mar 4, 2009 at 12:57 PM, Mark D. Gerl <mg...@mmdesigngrp.com> wrote:
> In any case, and perhaps based purely on habit, I find it difficult to even
> write:
>
> NSStatusItem statusItem = [[[NSStatusBar systemStatusBar]
> statusItemWithLength:NSVariableStatusItemLength] retain];
>
> ...in favor of:
>
> NSStatusBar *systemBar = [NSStatusBar systemStatusBar];
> if (systemBar != NULL)
> {
> NSStatusItem statusItem =
> [systemBar statusItemWithLength:
> NSVariableStatusItemLength];
> if (statusItem != NULL)
> {
> [statusItem retain];
> ...
> }
> }
>
> There's something that's just "uncomfortable" about dereferencing pointers
> without first checking for validity. Is it just me?
No "dereferencing" of pointers take place in the first version... If
you attempt to send a message to a pointer that is nil the Objective-C
runtime simply doesn't send the message (aka no attempt to deference
the pointer).
In your second version you are basically duplicating what the runtime
is already doing for you... why right more code then you need. Of
course you need to understand what happens with the return value when
you send a message to nil but once you understand that you can write
fairly clean code that will handle nils correctly.
Review the following...
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_2_section_4.html#//apple_ref/doc/uid/TP30001163-CH11-SW7
-Shawn
_______________________________________________
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 arch...@mail-archive.com
