Re: self = [super init] debate.

FROM : Quincey Morris
DATE : Sun Feb 10 20:29:16 2008

On Feb 10, 2008, at 09:18, Scott Andrew wrote:

> -(id) init
> {
>     self = [super init];
>
>     if (self != nil)
>     {
>         .. do my init
>     }
>
>     return self;
> }
>
> So my question is:
>
> As i get ready to teach non-cocoa programmers in my company about 
> cocoa programming, and having read Will Shipley's blog, Is the above 
> the way to teach writing an initializer? I see Will, and a few 
> others, say no [super init] will initialize self in its code there 
> is no reason to assign self. Yet all code and docs I see have 
> similar code.


The short answer: do the assignment to 'self'; it's wrong to omit it.

The long answer:

You can't rely on the discussion in the comments section of Shipley's 
blog, because it's effectively all off-topic. (Well, half of it is 
just plain wrong, and the rest of it is stuck on an irrelevant 
example.) Shipley's argument is basically this: if X is a subclass of 
Y, and the [super init] in X's init returns something other than an 
instance of X (partially initialized by Y's init), then the subclass 
can't work -- where would the subclass's instance variables be, for 
example? -- therefore, the [super init] must in fact return the 
instance you sent the [super init] to.

That discussion was using something like NSArray as an example, since 
"creating" a NSArray actually creates a private class instance. So you 
write:

@interface ArraySubclass : NSArray {
  int myIvar;
}
...

- (id) init {
  self = [super init]; // assume this returns a private class instance
...
  myIvar = 5; // oops -- the private class doesn't have this
}

Shipley tried to conclude from this that the "self =" assignment was 
at fault. In fact, what the example actually shows is that you cannot 
usefully subclass NSArray (or any other class cluster like it). That's 
why there are pages of Cocoa documentation explaining what to do 
*instead of* mistakenly subclassing NSArray.

Slightly more generally, it shows that there is a *condition* for a 
subclass to be legal: the result of its calling [super init] must be 
something that works as a partially initialized instance of the 
subclass. If you're not sure of that, don't try to subclass.

The other flaw in Shipley's conclusion is that, even if X's [super 
init] returns an instance of X, it may not be the instance you sent 
the [super init] to, so you'd better remember the returned value.

For example, it's not hard to imagine that the superclass Y's init 
might copy the instance to a different memory zone and return the 
copy. Y might need some knowledge of objective C internals to make 
something like that feasible, but Apple tells us to assume that a 
different instance might be returned, so it seems wise to believe them.