Posted at 2007-11-30 23:12 | RSS feed (Full text feed) | Blog Index
Next article: The Cults of Programming
Previous article: Algorithmic Optimizations: a Case Study
Tags: cocoa leopard objectivec rant
Next article: The Cults of Programming
Previous article: Algorithmic Optimizations: a Case Study
Tags: cocoa leopard objectivec rant
Leopard: First Impressions
Leopard's been out for a while now and brings with it a lot of interesting new tools for the Mac programmer. I've had the chance to work with some of them and want to offer my opinion on how they've worked out.
I won't be discussing Leopard from the user's perspective. Suffice it to say that it seems solid, and I haven't regretted upgrading from Tiger yet.
Now on to the meat of the post. Here's a list of new features I've worked with and how they've worked out for me so far:
- Garbage Collection
This is the great big granddaddy of all the new Leopard features. Apple added GC to Objective-C, a task many thought impossible, and many more thought would be doomed to mediocrity. But Apple forged a path right down the middle, carefully limiting the collector's scope to protect it from many of the more painful aspects of C while still making it useful for typical Objective-C use. There are a few painful corner cases but then again, there were painful corner cases with the old style of memory management too. Overall it makes writing new code pretty nice.
Verdict: Four stars - Objective-C 2.0
Considering the rest of Apple's additions to Objective-C, I am forced to cry out in a Homer-Simpson-like voice: booooooring! Properties are unexciting syntactic sugar, and the C++-like overloading of the = operator is mildly disturbing. The new for loop syntax is nice but doesn't do anything significant that my own home-rolled foreach macro hasn't done for me for years. And the rest... wait, there's nothing else! Compare this with the features Apple/NeXT has added to the language before without changing the name: built-in exceptions and synchronization, protocols, categories.
Verdict: Name obviously dictated by marketing - Xcode 3
Just like moving from Project Builder to Xcode, moving up to Xcode 3 is made out to be a big event, but then you arrive and discover that it's the same old app with a new coat of paint. After tweaking my settings a bit the first day, I can hardly tell the difference from Xcode 2. Refactoring seems pretty useless. Snapshots bring nothing to the table that version control hasn't done for decades, and if you aren't using version control then you're just asking for pain. Apple claims the editor is faster, which is good, but my machine is too fast and my files too small to notice. Inline error and warning messages are alternately great and tremendously annoying. It's still buggy and weird and it's still better than anything else on the Mac for making Cocoa apps.
Verdict: Meh - Interface Builder 3
Now this one actually deserves the name. It's a big change from IB2. Most of the change is even good. A lot of weird bugs and stupid limitations in IB2 are gone. The new inspector is good once you get used to it. The searchable palette is nice, although I think it's slightly harder to navigate than the old palette when not using the search box. Automatic synchronization with changes in Xcode is a definite plus. The new xib format could be better but even so it should solve a lot of problems with using nibs in group projects.
Verdict: A true upgrade - Instruments
Apple's shiny new all-in-one instrumenting application replaces a bunch of separate applications that I've known and loved for a long time. It takes some getting used to, but overall I think the change is a good one. The main downside is that Instruments can get very resource hungry when given the right stuff to monitor. It's made me glad I have 7GB of RAM because I have seen this single application use more than half of it all by itself.
Verdict: Not bad, but needs a diet - CoreAnimation
Animator proxies are a great idea and make basic use of CoreAnimation roughly sixteen times simpler than NSViewAnimation. I haven't used any of the actual CA classes yet but they look to be very powerful. On the downside, the promise of transparent animation, where we could use the animator proxy to update a property, and internally it would update instantly while visually it would animate to the new value, appears to have been broken despite still existing in the AppKit release notes. This may simply be a bug in the frameworks, or it may be that Apple changed their minds. If the latter it's pretty disappointing. I've filed this as rdar://5614088.
Verdict: Nicely done - CFStringTokenizer
This one probably prompts a "huh?" from the readership. CFStringTokenizer does just what it says on the label: you feed it a string and it feeds you tokens. These tokens can be paragraphs, line breaks, sentences, and even individual words. That may not sound impressive until you realize that it will do this even for languages like Chinese and Japanese which don't use spaces. You can also feed it a blob of text and it will tell you what language the text is written in. Probably not something a lot of people will really use but personally it's a really nice, simple interface to some powerful stuff.
Verdict: Sweet - Miscellaneous API additions
Leopard brings a host of small improvements to Cocoa, such as the newly exposed NSCodition class, the ability to manually schedule NSURLConnections, NSBundle unloading, threading and multiprocessing enhancements, NSTrackingArea, NSGradient, and many more. These little additions fill gaps and add nice, easy new functionality.
Verdict: It's about time - 64-bit support
This one isn't all that important yet, but it's getting there. Apple has been shipping 64-bit computers for years, and every Mac shipping today is 64-bit. The 4GB address space which once seemed to be limitless is now getting to be pretty small. Instruments could definitely stand to be a 64-bit app right now, and a lot of other useful applications for it will undoubtedly appear. The lack of Carbon GUI support is unfortunate but not too surprising. The way Apple handled it, by promising Carbon 64-bit and then changing their minds a year later was a total kick in the pants to everyone with a Carbon app, but the writing has been on the wall for a while.
Verdict: Glad I don't write Carbon GUI code
So there you have it. Although most of the code I write must remain Tiger-compatible for quite some time, I look forward to when I can take advantage of the new OS more completely.
Did you enjoy this article? I'm selling whole books full of them! Volumes II and III are now out! They're available as ePub, PDF, print, and on iBooks and Kindle. Click here for more information.
Comments:
Nice post.
How is transparent animation broken? Do you have an example?
How is transparent animation broken? Do you have an example?
My comments about properties apply to all aspects of properties. Yes, it's less cookie-cutter code, and that is nice, but it's not really all that special. This certainly does not deserve the fawning I've seen people direct toward the new syntax. And the fact that the automatically-generated accessors use locks is worse than useless, as it only encourages the misconception that thread-safe accessors are either necessary or sufficient for thread-safe code. Apple has actively encouraged this stance in documentation about both the properties syntax and garbage collection, which is unfortunate.
The fact that the new for loop syntax is implemented very efficiently is nice but it's really hard to care about this fact. I can't remember having ever written a speed-critical loop in which the overhead of iteration was even remotely significant. It's certainly good that it's not creating NSEnumerators and sending a message for each iteration under the hood, but the fact that my foreach macro does exactly that has never impacted the performance of my code in any visible way.
For transparent animation, first I will quote the release notes which describe how it's supposed to work:
The primary difference under Core Animation-based compositing is that for intrinsic geometric properties such as the view's "frame," all animation is handled at the Core Animation level, meaning that the view's property will be immediately set to the desired target value, and the view won't see the successive intermediate values. The animation effect in such cases is purely visual and exists only in Core Animation's "render tree" backend.
And then this simple code will demonstrate the fact that this is not actually the case:
The two log statements will display exactly the same values, even when the view is set to be layer-backed. Given the release notes, I expect the second log to display
The fact that the new for loop syntax is implemented very efficiently is nice but it's really hard to care about this fact. I can't remember having ever written a speed-critical loop in which the overhead of iteration was even remotely significant. It's certainly good that it's not creating NSEnumerators and sending a message for each iteration under the hood, but the fact that my foreach macro does exactly that has never impacted the performance of my code in any visible way.
For transparent animation, first I will quote the release notes which describe how it's supposed to work:
The primary difference under Core Animation-based compositing is that for intrinsic geometric properties such as the view's "frame," all animation is handled at the Core Animation level, meaning that the view's property will be immediately set to the desired target value, and the view won't see the successive intermediate values. The animation effect in such cases is purely visual and exists only in Core Animation's "render tree" backend.
And then this simple code will demonstrate the fact that this is not actually the case:
NSLog(@"%@", NSStringFromRect([view frame]));
[view setFrame:newFrame];
NSLog(@"%@", NSStringFromRect([view frame]));
The two log statements will display exactly the same values, even when the view is set to be layer-backed. Given the release notes, I expect the second log to display
newFrame, but it doesn't.Objective-C 2.0: I believe GC and the new 64-bit non-fragile runtime are included in the label. Also, you missed:
* @optional
* Properties can be introspected for semantics, e.g. retain/assign/copy, although there doesn’t seem to be a high-level interface, so you need to parse undocumented strings.
* Properties are also the only way to define private variables which aren’t listed in the header under the 64-bit runtime, although it looks as though this can be fixed.
So, er, whoo. Um. :-)
* @optional
* Properties can be introspected for semantics, e.g. retain/assign/copy, although there doesn’t seem to be a high-level interface, so you need to parse undocumented strings.
* Properties are also the only way to define private variables which aren’t listed in the header under the 64-bit runtime, although it looks as though this can be fixed.
So, er, whoo. Um. :-)
I deliberately separated GC from the rest since I think it deserves its own spot. I realize it's lumped into the "2.0", but I still think it's totally a marketing name.
The 64-bit runtime itself is just the logical continuation of 64-bit support. The fact that it eliminates the fragile base class problem is nice but of little practical value for most of us. It's hard to include this in the "2.0" when it's only available for 64-bit. A more significant 64-bit only feature is the unified ObjC/C++ exceptions model and zero-cost exceptions.
As for the rest, I forgot about those. Properties introspection is interesting although I can't immediately think of a use for it, but I'm sure someone somewhere will find one.
The 64-bit runtime itself is just the logical continuation of 64-bit support. The fact that it eliminates the fragile base class problem is nice but of little practical value for most of us. It's hard to include this in the "2.0" when it's only available for 64-bit. A more significant 64-bit only feature is the unified ObjC/C++ exceptions model and zero-cost exceptions.
As for the rest, I forgot about those. Properties introspection is interesting although I can't immediately think of a use for it, but I'm sure someone somewhere will find one.
Comments RSS feed for this page
Add your thoughts, post a comment:
Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.
Do you just mean the dot syntax? Synthesized properties mean that much less annoying cookie cutter code to type, and also enable the compiler to take care of locks if necessary.
>The new for loop syntax is nice but doesn't do anything significant that my own home-rolled foreach macro hasn't done for me for years.
This feature is not just syntax, but allows speed improvements as well. It enables any conforming collection class to pass back a direct pointer to its internal storage when possible, or at most do some quick copies of pointers into preallocated memory. I think that's a pretty cool language addition.
Thanks for the heads up about CFStringTokenizer...I think I'd come across an older Apple-provided library that did some of that, but nice to know it's a part of Cocoa now! That will be a fun class to play with.