Objective-C 2.0

December 27, 2006 at 8:24 pm

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.

Share this: Twitter

Facebook

Like this: Like Loading... Related

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