if(self = [super init])[world crashAndBurn];

I love Objective-C in a number of ways; True polymorphism, message passing, named arguments, lots of runtime flexibility, and the power of C right at your fingertips when ever you need it (but you don’t have to). But I have one, albeit stylistic, objection.

The [super init] nil checking in the init method of subclasses. Why would you want to, as a general rule, return nil as your newly constructed object? Why would you ever want your application to continue on its happy way sending messages to a nil object, an object you explicitly asked to be created out of a very specific class. Yikes.

If your parent fails to initialize the entire world should come crashing down. It is likely to do is later anyway after you ask the nil object to do something useful (other than return nil). If something is that wrong I want to know about it right then, right there, in that init, not 6 steps later after I take that object and do something useful with it.

I fail to see any sort of systimatic use for this nil checking of super in the init method. I could see some very limited usage but if [super init] ever decides to return nil I am going to have a real &*^%& of a bug to fix.

I would also like to add some confusing and contradictory from the same page of the Apple supplied documentation …

Subclass implementations of this method should initialize and return the new object. If it can’t be initialized, they should release the object and return nil.

And in the next paragraph they state …

Every class must guarantee that the init method either returns a fully functional instance of the class or raises an exception.

WTF?!