Re: alternate pattern for object initializers
Re: alternate pattern for object initializers
- Subject: Re: alternate pattern for object initializers
- From: Stuart Malin <email@hidden>
- Date: Sun, 25 May 2008 21:25:40 -1000
On May 25, 2008, at 8:51 PM, Kyle Sluder wrote:
On Mon, May 26, 2008 at 1:47 AM, Stuart Malin
<email@hidden> wrote:
As I said, my pattern is just a convenience:
Actually, it's not. You've just made -init the designated
initializer.
I guess I have. So, would a reasonable definition for "designated"
initializer be: it is the initializer that calls the superclass's
initializer?
Therefore if -init does not result in a valid state for
your object, you have a bug on your hands.
And for future reference, make sure that you test for self != nil in
your initializers. Otherwise you could get a crash earlier than would
be useful.
True enough. I 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. And so, regarding
the != nil test, while I often see this idiom used:
self = [super init];
if (self != nil) {
// do stuff
}
return self;
I tend to write:
if (self = [super init]) {
// do stuff
}
return self;
I'm sure my penchant for this terseness comes also from my years of
writing Perl. For the sake of recognizability (consistency) with
Cocoa idiom, would you say the former is preferred? (or worse, am I
overlooking a problem with the latter?)
_______________________________________________
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