tags:

views:

172

answers:

4

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.

A: 

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.

jer
then why can't I just call `[super init]` without returning the result as self? self is modified locally anyway as far as I understand.
Michael
And what is self then? You are saying "I am now the object that `[super init]` returns."
bddckr
so doing `return [super init]` is not valid? If I modify self it will be only in the scope of `init` method
Michael
If you `return [super init]` you might as well not bother with an init method at all - then `[super init]` will effectively be called directly.
JeremyP
+10  A: 

You mean why

self = [super init];

rather than

[super init];

Two reasons:

  1. in initialisation, failure is indicated by returning nil. You need to know if initialisation of the super object failed.
  2. the super class might choose to replace the self returned by +alloc with a different object. This is rare but happens most frequently with class clusters.

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.

JeremyP
Good catch with the much overlooked reason two. Nice answer!
Niels Castle
@JeremyP: so there are two points I would like to clarify. To bubble `init` results from top to my class and my subclasses, 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? 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. So I may also need to check the class returned by `super init`.
Michael
@JeremyP: thanks for update indeed. That explains and made a lot more clear for me. Will need to ask couple more questions to draw full picture in my head, will do that in separate question.
Michael
A: 

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.

sdolan
@sdolan: You could have used some `id tmp = [super init]` then `return id`. What's the point of using `self`?
Michael
The call to [super init] does not return a temporary object, it sets up and modifies your instance, which you then customize more with your custom instantiation.
sdolan
+1  A: 

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.

Ferruccio