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: glenn andreas <email@hidden>
- Date: Fri, 18 Aug 2006 15:09:49 -0500
On Aug 18, 2006, at 2:53 PM, John McLaughlin wrote:
Hi All,
The consensus seems to be to have a private init function
('setDefaults') and then all of your inits' can call that. Seems a
reasonable approach that is certainly maintanable but a large part
of me still wonders that unless you need to call the parents
initWithCoder or unless you are doing something in your init that
is painful (time or resource wise) the most elegant solution would
still be to call [self init] first -- It guarantees an object's
starting point is the same whether loaded from a coder or
instantiated brand new and it really (again, to me) has a certain
elegance to it.
In general, you should only call an initializer once on an object -
so calling [self init] and then [super initWithCoder:] could cause
problems.
Consider a simple example:
@interface Foo : NSObject<NSCoding> { NSMutableDictionary *dict; }
@end
@implementation Foo
- (id) init
{
self = [super init];
if (self) {
dict = [[NSMutableDictionary dictionary] retain];
}
return self;
}
- (id) initWithCoder: (NSCoder *)aDecoder
{
self = [super init];
if (self) {
dict = [[aDecoder decodeObject] retain];
}
return self;
}
@end
If you make a subclass of Foo and in your initWithCoder call [self
init], that would end up allocating dict (in -[Foo init]), and then
[super initWithCoder:] will decode another dictionary, leaking the
old one.
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium2 | build, mutate, evolve, animate | images, textures,
fractals, art
_______________________________________________
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