Objective-C 2.0

December 27, 2006 at 8:24 pm 3 comments

As many of you know, Apple is releasing the new incarnation of Objective-C (creatively dubbed Objective-C 2.0) along with XCode 3.0 and Leopard. Though much of it is hidden under Apple’s elaborate nondisclosure agreements, people like Andy Matushack and Scott Stevenson as well as other sites have uncovered more information from the ObjC mailing lists and repositories than the meager scraps of info that Apple released on their website.

Since I can’t give any new information about this, I’ll just list my opinions, then brace for the reaming I’ll receive in the comments.

Disclaimer: Apple may change all of these things. This post is naught but conjecture heaped upon conjecture.

The Good

1. The foreach loop.
It’s simple, but makes lives easier when we don’t have to mess about with NSEnumerators for standard iteration. Here’s how one iterates through an NSArray of objects:

for (id tempString in theArray)
// do things here

It’s very reminiscent of the Python for loop:

for ii in someList:
# do things here

It’s also much easier to understand immediately than the Java 5.0 foreach loop, which inexplicably uses a colon to indicate “in”:

for (Object ii : someSet) {
// do things here

This is a simple thing that I will appreciate very much; it saves me from messing about with standard C for loops or NSEnumerators. I’m glad they picked the Pythonic syntax, as it’s far more readable.

2. Garbage collection.
To be honest, I know next to nothing about how garbage collection works. I do know that though memory management in Cocoa is much better than in C++, garbage collection is always welcomed; if they make it both quick to use yet optional (like the D language has), it seems everyone will be happy.

3. More explicit support for protocol methods.
Now, instead of blindly hoping that I remembered to implement all the methods for a protocol, I can be warned by the compiler that I need to implement certain ones. By using the @required and @optional directives, one can specify that certain methods must be included in classes that implement a given protocol. This seems like a step in the right direction – after all, what’s the point of implementing protocols if you don’t remember to code the correct methods?

The Okay, I Guess

[This section was changed, as what I previously had here was not new to the language.]

1. Official support for attributes on method calls.

According to this article, we will be able to specify that methods are unavailable/deprecated/what have you – inside the code:

- (void) foo __attribute__ ((deprecated)) __attribute__ ((unavailable));

The above was taken directly from the repository, so it should be canon.
I don’t really know what to think about this; though news about method deprecation would be nice, perhaps Java’s @deprecated JavaDoc tag is more elegant.
The (Hideously) Ugly
1. Properties
I was around halfway through a really venomous diatribe on why properties are such a bad idea when I remembered David Young‘s entry Does Objective-C Really Need Properties? He provides a far clearer case against them than I ever could; go read the article. In fact, his article pretty much supersedes mine. *cries*

We may will learn new things about ObjC 2.0 in the future, things that may put a spring in our steps and smiles in our hearts. But right now, I am without both – I’m afraid that Apple went overboard with the syntactic sugar.

Feel free to tell me how wrong I am in the comments.

Entry filed under: apple, cocoa, code, objc.

NSManagedObject: better than sliced bread? (Yes.) How to Beat Rails


  • 1. Scott Stevenson  |  December 27, 2006 at 10:31 pm

    There’s a good reason for the access control stuff, though I’m not sure it’s public yet.

    As for properties, there are some minor drawbacks, but I don’t think it’s realistic to hold onto a C-centric view of the world until the end of time. The best thing Apple can do is maintain the important parts of the Objective-C runtime, and meet somewhere in the middle on syntax.

    Frankly, between door number one:

    value = [[[[object this] that] something] somethingElse]

    … and door number two:

    value = object.this.that.something.somethingElse

    I’ll take door number two.

  • 2. Mike Abdullah  |  December 27, 2006 at 11:41 pm

    Not wanting to upset, but I feel I ought to point out that the @private etc. directives are already in 10.4. In fact I think they’ve been around since Panther and earlier.

    I’m waiting to see what happens with the whole properties business.

  • 3. Jon H  |  January 2, 2007 at 12:21 am

    @private/@protected/@public go back to the early 1990’s, at least as far as being applicable to instance variables.

    I found them mentioned in a 1993 usenet thread in comp.sys.next.programmer.

About Me

I'm Patrick Thomson. This was a blog about computer programming and computer science that I wrote in high school and college. I have since disavowed many of the views expressed on this site, but I'm keeping it around out of fondness.

If you like this, you might want to check out my Twitter or Tumblr, both of which are occasionally about code.

Blog Stats

  • 709,136 hits

%d bloggers like this: