I find this init to be both easy and sane:

-(id)init;

{

if(![super init])

return nil;

myInitialization...

return self;

}

(Okay, very late to the discussion, it seems :-P)

In ObjC, you can catch method calls that cannot be handled and do something else with it, that's totally unthinkable in C++. Additionally, since Mac OS X 10.1, you can mix ObjC and C++ in a single source file using ObjC++.

I have to agree with several comments above - where you come from determines how you feel about Objective-C.

I'm new to Macintosh development but I've been writing Windows software using C & C++ for over ten years. I must admit I chose to work with Carbon over Cocoa largely becuase of hate #1 (and also because I'd like to share classs with a GTK application). Perhaps it's just an old dog refusing to learn new tricks, but the syntax seems convoluted to me. Methods are, ultimately, just functions with hiden member data passed to them so I fail to understand why they should have a different syntax.

I understand the NeXT legacy and I appreciate language diversity, but Apple is doing themselves a disservice by ignoring millions of C++ developers.

Hate 6:

You don't have to overwrite self in init.

It is perfectly fine and actually preferred to write init more like the following:

- (YourObject *)init;

{

YourSuperObject *superobject;

superobject = [super init];

if (superobject != nil) {

}

return (YourObject *)superobject;

}

Somewhere along the line people figured out that the compiler and practice of overwriting the self pointer didn't matter. Thus in the effort to save themselves from creating another variable they started writing the code as you showed. In reality, I write my init methods as a slightly shorter version of the above, mostly to save me typing:

- (YourObject *)init;

{

id rc = [super init];

if (rc != nil) {

}

return self;

}

Of-course this all gets back to writing more code than we really should have to. I also assume that the compiler optimizes my init to be fundamentally similar to your init.

Hate 11:

You can actually write your own class unloader. It isn't too hard to do this. The problems start when you want to reload the classes you previously unloaded. You have to save all of the information yourself and reconstitute it into the class hierarchy, since the classes were never really unloaded from memory just dereferenced. (There are other issues which I am not bothering to address, obviously, but I have written a class unloader and reloader and know it can be done.) Thankfully there is enough documentation of the runtime system for someone to do this if they are adventurous.

Hate 15:

Since I have been a NeXTstep developer since 0.8 beta, you bet I like the syntax. As you basically say in a roundabout way, there is nothing wrong with the syntax other than it isn't similar to the C++ style messaging syntax. Of course there would be problems if Apple tried to rewrite the syntax to look something like foo.bar(key:value, key2:value2, key3: value3) since it would interfere directly with the parsing of arguments of C and C++. [Yes, I know that the current Objective-C arguments are not named.] I prefer square brackets primarily because it helps make the Objective-C code jump out from the standard C and C++ code which I have to interact with.

You missed a really big hate about Objective-C: no class variables! I do know the workarounds, but would like to see Objective-C get real class variables.

I agree with the other posters that messaging nil is sometimes a good thing. I don't like having to track down that one instance of a nil object which isn't supposed to be nil either though. However, I can't think of a good way to allow me to have my cake and eat it as well so I will cope with having to finding those unwanted nil objects.

Finally, WebObjects, in Java _sucks_ compared to the Objective-C version. I could easily write the 15 things I hate about Java coming from the Objective-C world. (I could probably come up with 10 that I like as well, but the hate side wins regardless.) G*d-d*mn helper-class hell. Why Gosling thinks he invented an object-orientated language, when you *have to* write objects which are totally meaningless in-and-of-themselves, I will never know. Java definitely makes me write more code that I shouldn't have to than Objective-C does.

Mike Barthelemy

In that context, it's not strange to find that method calls have a different syntax than function calls. They're different things, after all, especially in a language like Objective C with dynamic binding.

When you're learning OO, I also think it's probably useful that the different syntax keeps the concepts of method and function separate. That way you can know "here I'm using a C function, not OO" and "here I'm using a method".

But if you're coming to Objective-C from a language which uses parens for both functions and methods, then it probably does look strange.

But yeah, I'm an old NeXT user. For what it's worth, Smalltalk has always looked weird to me. But Objective-C was my first OO language, and one of my first languages of any kind.

- Jon

PS: regarding the expressiveness (or not) of message calls, consider the case where a Java constructor invokes another constructor, and all you see is

this(foo, bar, baz) or

this(foo, baz), or

this(foo, bar).

and you lose what little information might have been provided in the method name.

Jonathan Rentzsch has written a great article about what he loves and hates about Objective-C. I’ve wanted to write this article for a long time, but now Rentzsch has saved me the time and also done a better job than I probably would have. Now I...

Why is it silly?