Re: self = [super init] debate.

FROM : Ricky Sharp
DATE : Sun Feb 10 21:01:25 2008

On Feb 10, 2008, at 1:29 PM, Quincey Morris wrote:

>
> 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.



I agree with what Quincey says here.  I know when I first started 
Cocoa, my inits were a bit different.  But, after reading many things 
(mostly from this list), I opted to keep all my inits in the following 
form:

if ((self = [super init]) != nil)
    {
    [self setPropertyA:someValue];
    [self setPropertyB:...
    }

return self;

The way I look at this, it may be that this pattern is overkill for 
many situations, but I've yet to see a case where this pattern is the 
wrong thing to do.  And by wrong, I don't mean saving a few keystrokes 
in typing; wrong in that some compile and/or runtime issue will come 
up.  I'd rather spend my time writing business-logic code than 
attempting to figure out just what init pattern may save me on typing 
and/or a few compute cycles.

Thus, I use this single pattern since I know it will work in all 
cases.  I also like more explicit code anyhow.  Even in Java, my 
constructors are usually like:

int x;
int y;

public foo(int anX, int aY) {
    this.x = anX;
    this.y = aY;
}

It's not necessary to use 'this', yet I prefer to always do that to me 
more explicit.

___________________________________________________________
Ricky A. Sharp        mailto:<email_removed>
Instant Interactive(tm)  http://www.instantinteractive.com