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.
Also included:
- Automatic @synthesize
- NSArray/NSDictionary subscripting, eg id object=MyArray[12];correction: Apple's Mac developer program. I'm an iOS developer and I don't see Xcode 4.4 in my dashboard.
As somebody who loves the long method names but of course wants less syntactic cruft, I'm really happy with their recent progress.
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.
If you're a Mac developer, check the forums. Else, wait for the info to be non-NDA.
These are all good changes (well, except for garbage collection, but hey, they kicked that out with ARC anyway), but it really is hard to stay up-to-date. Yeah, I know, woe is me, my tools supplier is constantly supplying better free tools, but it is daunting having to review each of this evolutions, and determine if it is worth the effort to integrate it into my project.
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...
Well, you don't really _need_ to; this one is just syntactic sugar, and the others, while nice (or mostly; I'm unconvinced about ARC), are not necessary. I'd prefer to have the options.
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.
When I want an array literal in C, I'd write ...
int foo[] = { 1, 2, 3, 4, 5};
NSArray *bar = @[o1, o2, o3];
I feel like the syntax for an NSString literal is more natural (as a C developer).
NSString *baz = @"look, an NSString literal";
char szBaz[] = "look, a C string literal"; [someObject dictArg:@{ a:@"B" } arrayArg:@[1,2,34]];
[1] http://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Romans...
id foo = @{ @2, @5 };
an NSArray containing two NSNumbers, or an NSValue containing a struct with two pointers (which happen to be NSNumber *s)?
I'd guess there were other edge cases they didn't want to deal with, so they didn't do literal NSValues for this release.
Or it could be that it's because []-style arrays are popular these days.
Or some of both; in picking which {} to change to @[], they reasoned that lots of people have experience with []-style arrays.
Who knows, but it seems to mirror Python in that respect. Being a fan of Python I can only approve.
On the other hand, it strengthens the coupling between Objective-C the language the Cocoa the framework, and I'm not sure how I feel about that.
I do like it better than the property dot syntax though. (is a simple assignment to a struct member? is it an objc_msgSend of unknown complexity?)
Also, there's long precedent with @"…" syntax for embedding NSString literals and most of the changes are really just preprocessor/static analysis-driven syntactic sugar — sometimes extreme sugar, yes, but optional, highly-predictable, purely-syntactic-cleanup nonetheless. So if they ever decide "the future of Cocoa is Ruby!" or something like that, I'd think most of the sugar could be, to mix metaphors, transplanted.
On that note, though: I don't see Apple moving primarily away from Objective-C any sooner than I see .Net moving primarily away from C#. It's "the language" until something huge changes the landscape, in large part because they've been able to so substantially evolve it, just like Microsoft, who also controls the primary framework used with their language, has been able to do with C#.
It does represent yet another link between the language syntax and the Foundation framework (along with NSStrings, blocks, etc), but Foundation is effectively part of the language.
return (struct x){a,b};
The definition of ObjC confuses me a bit. It's said to be a superset of C - but which C? C89? C99? GNU-C-Something?
Obj-C also includes the Foundation classes that were originally introduced with the OpenStep SDK in 1994 (NSObject, NSString, NSNumber, NSArray, NSRunLoop, NSAutoreleasePool, etc.).
Talking of OpenStep, after seeing some of those NeXT videos on HN the other day, I found a torrent of OpenStep 4.2 incl the dev tools. It's a VMware image and boots and runs just fine. Pretty nifty. Then I noticed OpenStep 5.0 redirects to Mac OS X on Wikipedia!