Let's say I create my class and its init
method. Why should I call and return value of superclass init
assigned to self? Which cases it covers?
I would appreciate examples why would I need it for Cocoa superclass and non-Cocoa.
Let's say I create my class and its init
method. Why should I call and return value of superclass init
assigned to self? Which cases it covers?
I would appreciate examples why would I need it for Cocoa superclass and non-Cocoa.
Because you have to initialize the object somehow, and presumably you want to do any initialization a superclass required be done, since you're descending from it.
You mean why
self = [super init];
rather than
[super init];
Two reasons:
Edited in response to Michael's comment:
I can understand why I need to save and return [super init]. But is it just convention and good looking makes us use self as a temporary variable to pass result along?
No. Instance variables are accessed relative to the self pointer, so in the following:
-(id) init
{
self = [super init];
if (self != nil)
{
myBoolIvar = YES;
// The above is an implicit version of self->myBoolIvar = YES;
}
return self;
}
self has clearly got to point to the right block of memory i.e. the one you are going to return.
The other point is that if super init returns different class instance then the rest of the code after that line may not even make sense, lead to memory leaks and crashes, not even talking about the object instantiated from that class.
That could be a problem. If I subclassed NSNumber and [super init] decided to return an NSString (which it could - there's nothing to stop it) that would clearly be a disaster. Whatever super returns from -init must be "compatible" with the subclass in the sense of providing space for ivars and being further subclassible or it's a horrendous bug (unless, of course, the problem is documented). So, in general, you don't need to worry about checking the class. However, do read the documentation. See for instance the section on subclassing NSString in NSString's docs.
Basically it comes down to best practices and clarity.
Take the two examples:
-(id) init {
[super init];
self.someArray = [NSArray array];
return self;
}
vs.
-(id) init {
if (self = [super init]) {
self.someArray = [NSArray array];
}
return self;
}
or perhaps better:
-(id) init {
self = [super init];
if (! self) {
@throw([NSException exceptionWithName: @"CallToSuperclassFailed" body: @"Instantiation of the super class failed" userData: nil];
}
self.someArray = [NSArray array];
return self;
}
For me the latter is much clearer on what's going on.
Also, if the call to super returns nil at least your object will fail to construct.
In most cases, setting self to [super init] does nothing since [super init] will wind up returning self anyway. There are some rare cases, however, where [super init] will return something different. It may return nil if it fails to initialize the superclass for some reason or it may decide to return a completely different object.