Re: alternate pattern for object initializers
Re: alternate pattern for object initializers
- Subject: Re: alternate pattern for object initializers
- From: Jens Alfke <email@hidden>
- Date: Mon, 26 May 2008 10:13:57 -0700
On 26 May '08, at 12:25 AM, Stuart Malin wrote:
have gotten lazy for classes that derive from NSObject, because if
I can't get a valid initialization back from NSObject, then I've got
a much bigger bug on my hands. That said, laziness may have been an
aspiration when I wrote Perl; perhaps now I should strive for
consistency and completeness.
If you're lazy (like me!) then what you *really* want to do is type
"init" and press the completion key (I can't remember the default key
binding for this; it's Edit > Next Completion in the menus. I bound it
to the back-quote key since I use it constantly.) This will fill in a
boilerplate init method for you. You can do the same thing with
"dealloc".
I tend to write:
if (self = [super init]) {
// do stuff
}
return self;
Putting assignments in 'if' statements is bad style, because it's very
easy to get them mixed up with the more common equality tests. In
fact, putting '=' instead of '==' in an 'if' is a common enough error
that GCC has compiler warnings for it, so code like the above will
actually generate warnings if someone turns on those flags. For that
reason, I would avoid using that syntax. A workaround for that is
if ( (self = [super init]) != NULL )
but I avoid that too. I just find that putting assignments into
conditionals at all makes the code confusing; but YMMV.
—Jens
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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