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: Ricky Sharp <email@hidden>
- Date: Thu, 17 Aug 2006 22:42:19 -0500
On Aug 17, 2006, at 10:26 PM, John McLaughlin wrote:
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]?
Not sure what examples you're looking at, but implementations of
initWithCoder: I've seen (as well as what I personally do):
- (id)initWithCoder:(NSCoder*)aCoder
{
if ((self = [super initWithCoder:aCoder]) != nil)
{
[self setThis:[coder decodeObjectForKey:@"MyThis"]];
[self setThat:[coder decode...
}
return self;
}
You often then have a designated initializer (perhaps just init) on
the object. In those inits, I just call the same accessors as I do
in initWithCoder.
Finally, for other non-archived attributes, or other things that need
to be set up, why not create a separate method (e.g. setDefaults) and
call it from both initWithCoder and your various other init methods?
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.
Am I missing something obvious here?
-John
John McLaughlin
http://www.loghound.com
email@hidden
_______________________________________________
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
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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