This is going to be a techy one. If you aren't familiar with/interested in Objective-C and you don't like confusion, you might want to skip this one. Otherwise, read on...
I came across this page today:
rentzsch.com: Love, Hate and Objective-C
If you read the blurb at the top of this post and are still reading, check this page out (the whole site looks pretty good too). What follows is my response.
First off, my
bias. I consider Objective-C to be my home language and Cocoa my home environment. I am also something of a traditionalist. That should cover it. On to the page.
The page is divided into loves and hates. I won't respond to the loves, since I basically agree with them all. I do want to quote one thing though, from
Love 5: Categories:
Trivia bit: iChat's InstantMessage.framework contains a category named NSViewShouldHaveAVisibleBitLikeEveryOtherFrameworkInExistance on NSView which adds visible and setVisible: methods. I fully agree guys, it's wacky we had to wait until 10.3 for this bit.
It's funny because it's true...
No, it's the brace syntax where my hate lies. Do you really believe:
[[[MyClass alloc] init:[foo bar]] autorelease]
is easier to read or write than:
MyClass.alloc().init(foo.bar()).autorelease()
Well...yes. I really took to the brace syntax. To me,
MyClass.alloc().init(foo.bar()) says to call the
init method of the
alloc method of
MyClass. In my head, the dot operator should only be used after a "noun", not a "verb". When I see brackets around an expression, I know I can treat it like a "noun" from the outside. Graphically,
alloc() only marks this on
one side. In fact, if I'm reading left to right as I usually do, I notice it
after I've read the word, so I've already thought of it as a "noun". Obviously others find this notation easier to read. That's cool. But understand that it's not universal.
The brace syntax is all about assisting the compiler to delimit an ObjC message send from the otherwise "normal" C code. Thus, it's there to aid the machine, not the programmer.
Actually, I find I get the same benefit the machine gets, for the same reason.
I will say one good thing about the brace syntax: because it makes nesting method calls painful, it encourages conformance to the Law of Demeter.
I like that too.
ObjC is a mediocre language propped-up by a great framework.
Yeah, I'll buy that. I kind of like it that way, though. Maybe I just lack imagination.
Raw pointers are evil and must be stopped.
I
love raw pointers. Why? Because I actually understand what I'm doing and what the machine is doing. It's down-to-earth, not abstracted-all-to-hell. That's one thing I love about Objective-C. I think I've had more trouble with pointers working in languages that didn't let me actually touch them (like scheme) than in Objective-C. I know there
are pointers in there somewhere. If I can't see them, it just confuses me.
More importantly, I had a hard time justifying learning a new language that lacks garbage collection.
On the contrary, I had a hard time justifying learning a new language that
has garbage collection: Java. I don't want to hand memory management control over to some black-box garbage collector I can't trust. Who knows when my objects will be deallocated? I've seen the results, and it isn't pretty. No thank you.
And what's so hard about the Cocoa system? If you want to be sure an object doesn't disappear, -retain it. If you don't need it anymore, -release it. It's elegant.
...it is wrong that all code everywhere must separately call both +alloc and -init, in the right order.
I used to try to follow the great Usenet discussions (read: flame wars) over this issue. I was always in favor of calling
+alloc and
-init. When I read this, though, I remembered that the Cocoa frameworks are covered with methods like
+[NSFoo foo], which really just calls
[[[NSFoo alloc] init] autorelease]. So what's the issue? The number of calls to abbreviate? I'm all in favor of standardizing
+new methods.
Yeah, I'd like to see some lingual support for this. In general, a class should be able to tell the compiler what methods a subclass ought to override. That way subclassers can be warned if they don't. That's the Objective-C style. Why isn't it in there?
Coming up...Part 2: Hates 6–10.