Objective-C literals for NSDictionary, NSArray, and NSNumber(cocoaheads.tumblr.com) |
Objective-C literals for NSDictionary, NSArray, and NSNumber(cocoaheads.tumblr.com) |
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.
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";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!
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.
[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.
I really don't see the logic in withholding from paying members of either platform.
Interestingly now Xcode 4.3 is out of beta the iOS 5.1 SDK is still only available with Xcode 4.3 DP3 (although realistically there's not much public new stuff in iOS 5.1 since presumably it's all under wraps for the iPad 3).
Xcode 4.1 was part of the Lion pre-release, so I don't think that iOS developers got it during beta, though apparently it was made available for SL users a few weeks after Lion shipped.
It at least makes sense to limit the betas to the Mac program only if the tool in question only works on a prerelease OS (I assume that's the case with 4.4 and ML). But limiting it to iOS developers only makes no technical sense at all.
Edit: 4.4 works on 10.7.3+, so yeah, this is just the usual bullshit.
id foo = [self bar];
id foo = self.bar;
id foo = [self performSelector:@selector(bar)];
IMP barImp = [self methodForSelector:@selector(bar)];
id foo = barImp(self, @selector(bar); [1]
id foo = ((id)(id, SEL)objc_msgSend)(self, @selector(bar)); [2, 3, 4]
2. Casting the function is optional, but, helps to prevent things like endian differences and your return value getting mangled when using the same code on PPC and Intel. Not too big of a deal anymore.
3. There are actually two other varieties of objc_msgSend, depending on your return type — specifically, floating point calls should use objc_msgSend_fpret and calls that return a struct should use objc_msgSend_stret.
4. I hope I got this cast right, I didn't try to compile it.
objc_msgSend(self, @selector(bar));
objc_msgSend(self, @selector(performSelector:), @selector(bar));
?They would both become:
objc_msgSend(self, @selector(bar));
For the second to work, the objc_msgCall function would really be:
objc_msgSend(self, @selector(performSelector:), @selector(bar));
The runtime may or may not be smart enough to optimize this out. It has never been a bottleneck for me to bother looking into it, and I haven't come across anything to indicate one way or the other.