21–30 of 58 posts
Nice. I wish for ability for function to return multiple values. Is it possible at all?
You can use C99 struct literals: return (struct x){a,b}; Small structs may be passed in registers. http://stackoverflow.com/a/3355560/27009
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?)
Earlier quoted context omitted.
> but it really is hard to stay up-to-date. 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.
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.
On one hand, it's nice, and it'll make coding in Obj-C nicer. 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#.
The excessively verbose collection syntax is my #1 pain point with Obj-C. Looking forward to kicking the tires on this one.
As somebody who loves the long method names but of course wants less syntactic cruft, I'm really happy with their recent progress.
This is for Apple LLVM 4.0 which ships with XCode 4.4. Also included: - Automatic @synthesize - NSArray/NSDictionary subscripting, eg id object=MyArray[12];
For those wondering: Xcode 4.3 is what currently ships, 4.4 Developer Preview ships with the Mountain Lion per-release, so it only is available to those in Apple's Developer Program.
Earlier quoted context omitted.
For those wondering: Xcode 4.3 is what currently ships, 4.4 Developer Preview ships with the Mountain Lion per-release, so it only is available to those in Apple's Developer Program.
> ...so it only is available to those in Apple's Developer Program. correction: Apple's Mac developer program. I'm an iOS developer and I don't see Xcode 4.4 in my dashboard.
I really don't see the logic in withholding from paying members of either platform.
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";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.