Objective-C literals for NSDictionary, NSArray, and NSNumber

It's not as simple as that when you're planning for the long term. Firstly you need to examine the changes and make sure that they aren't going to create any compatability problems, of the type "if you activate this option, then you can no longer link to libraries that don't use this option". Garbage collection in particular had a lot of those sorts of problems.

But even if you can convince yourself that it is just syntactic sugar, you have to have a long hard think about whether or not you are going to adopt the style. Adopting means going back and changing the code you have already written. Not adopting the style is not tenable in the long term - the new syntax is clearly superior to the old syntax, so there will be a lot of pressure to code the new way. This is particularly true when playing in Apple's backyard, as they have a habit of taking a nice new technology that is optional in one release, and then building on that optional feature for a next release.

For me, in this one particular case, I'll probably go with the new syntax, going back through modules that are already written and redoing them with the new syntax each time I have to touch one for a bug fix/feature.

I'm just getting frustrated because my project started about 18 months ago - I work on it nights and weekends, and I have to keep stopping work on the project and spending time adapting to new tools. The last 18 months or so have been particularly tumultuous. XCode 4 was a big change compared to its predecessors. I started using the garbage collector just to have it more or less replaced by ARC.

None of this is insurmountable, but as a one person, part-time shop with a fairly ambitious project, this is really starting to become painful for me, which is the point I was trying to get across, and I suspect that I'm not the only one to be feeling the pain. Perhaps I would feel better about deciding not to follow Apple on this one if I could be sure that that decision wouldn't mean me finding myself with a big code base on my hands that is unable to take advantage of the new hotness in the next version of Objective-C because I decided to skip this version's changes...

ARC is not really 'needed' for anything, it's just a very nice way to prevent memory leaks and pruning lots of retain/release statements from your code.

I would not re-factor existing code without ARC if it was properly debugged for memory leaks and working perfectly, but for all new projects I have it enabled.

@-prefixed literals for collections are definitely welcome (I won't miss those nested 'dictionaryWith...' calls for sure).

Anyone know how the []-access will work? Is this going to be a special case for NSArray/NSDictionary synthesized in by the compiler, or is there going to be runtime support for a []-operator message a la Ruby, or maybe something related to key-value coding?

I hope this is done coherently, anyway. I worry that too many special cases to overcome problems like verbose collection access could snowball.

There are methods you can implement in your own classes to provide setting and getting for both the array and dictionary style syntax.

If you're a Mac developer, check the forums. Else, wait for the info to be non-NDA.

Well, I guess that was long overdue. Anyway, another nice step to bring Objective-C forward.

It seems to develop into a nice combination of low-level, high-performance C and a pretty straightforward, dynamic, object system. In short, I vastly prefer its object system to C++, because it reasonably trades some performance for greater dynamisms and an easier syntax.

It'll be interesting how Objective-C will develop.