self = [super init] revisited

Question

I stumbled upon this post In Objective-C why should I check if self = [super init] is not nil?

I can understand this syntax:

- (id)initWithString:(NSString *)aString
{
    self = [super init];
    if (self)
    {
        instanceString = [aString retain];
    }
    return self;
}

or this syntax:

- (id)init;
{
 if (!(self = [super init]))
   return nil;

 // other stuff
 return self;
}

but I still don't understand the "standard" template syntax

- init {
    if((self = [super init])) {
        // set up instance variables and whatever else here
    }
    return self;
}

Can someone tell as clearly as possible what (3) does more or less compared to (1) or (2) ? All I read is so confusing (why people can't agree with something which is purely technical seems like politics :))

Nevertheless as I read authors article, and as I can fuzzily understand it goes far beyond just syntactic sugar debate or matter of taste. For example it is said:

Curiously then, while case 3 is overwhelmingly more common, initializers that support 1, 2 and 4 but are incompatible with case 3 have become the standard.Curiously then, while case 3 is overwhelmingly more common, initializers that support 1, 2 and 4 but are incompatible with case 3 have become the standard.

So I'd like to have a deep philosophical answer from Objective C Gurus if possible.

Answer 1

The key to understanding (3) is the if line

if((self = [super init])) {

In C, every operator has a return value, you just don't have to use it. So just as 3 + 4 returns 7, the operator = returns the same value that was just assigned. That allows you to do interesting things like this with it:

int a, b, c, d;

a = b = c = d = 5;

(This works because the operator has right-to-left associativity. This means that a = b = 3;is equivalent to a = (b = 3); so b is set to three first, then a is set to that same value.)

So now we can observe that the test

if((self = [super init])) {

is exactly the same as

self = [super init];
if (self) {

They all do exactly the same thing, though. As for the preferred option, a lot of people think that putting expressions into if statements is bad practice, as it's hard to notice if you're not used to it. Apple do seem to have settled with the first example you listed in their templates, and have also added a compiler warning for the first, if you try to do it without the stupid double brackets if(()).

Answer 2

All of the three accomplish the exact same task: call [super init], assign it to self (in case super's init returns a different object, which in some cases is possible) and test whether that returned pointer is nil. If it is nil, leave without doing anything else.

Examples #1 and #3 are identical, they just have the syntax slightly rearranged. #2 is different in that it returns an explicit value of nil, while #1 and #3 do so implicitly.

Which on to use is a matter of taste. I prefer #2 because it saves an indention level (I like to avoid indention if possible, because if you have indented four or five levels deep it really gets hard to follow the flow).

People do not universally agree which one to use for the very same reason they cannot agree which indention style (K&R, Allman, GNU, Whitesmith, ...) to use: it's personal preference and does not change the logic.

Answer 3

If you have an variable and no ==, !=, > or something like that the expression will be true if your variable (in this case a pointer to an object) is not 0. That means if your pointer don't point to nothing. nil and NULL are defined for 0 so you can write

if ((self = [super init]) != nil) {}

or

if ((self = [super init]) != NULL) {}

or

if ((self = [super init]) != 0) {}

or simply

if ((self = [super init])) {}

too.

Answer 4

I also prefer the extra "room" afforded by NOT using the overly verbose, rarely intuitive... and frankly ugly syntax I see in Apple's code / around town, etc...

-(id) init {  if (self != super.init) return nil; ...

I may be drowning babies - and causing handsome old Indians to weep in the process - but I just stick it all on one line... and remember to return self; AOK so far!