Re: [self init] vs. [super init] in initWithCoder
Re: [self init] vs. [super init] in initWithCoder
- Subject: Re: [self init] vs. [super init] in initWithCoder
- From: Greg Hurrell <email@hidden>
- Date: Fri, 18 Aug 2006 05:39:24 +0200
El 18/08/2006, a las 5:26, John McLaughlin escribió:
I was pounding my head against a bug last night that ended up being
caused by the fact that I had used [super init] within
initWithCoder instead of [self init] (I set up some notifications
in [self init] that, well, weren't being set up)
It got me to thinking, it seems the convention is to call [super
init] within initWithCoder, most code examples do this. Is there a
reason you wouldn't as a rule call [self init]?
The only reason I can think of offhand is a little performance hit
(since possibly you are creating object in [self init] that you
promptly overwrite in initWIthCoder) but except for that I really
can't think of a good reason not to call [self init] (which, of
course, will call [super init]) and it seems to me to be a best
practice.
init and initWithCoder are two different pathways for initializing an
object. They're independent and I don't think one should call the
other, and I've never felt the need to. I think this is explained
fairly well in the docs. But sometimes there are things that you
would want to do in both cases, and for that reason I often use this
pattern:
- (void)commonInit
{
// stuff that is common to both init and initWithCoder:
}
- (id)init
{
if ((self = [super init]))
{
[self commonInit];
// plus stuff that is unique to init...
}
return self;
}
- (id)initWithCoder:(NSCoder *)decoder
{
if ((self = [super initWithCoder:decoder]))
{
[self commonInit];
// plus stuff that is unique to initWithCoder...
}
return self;
}
G _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden