mikeash.com: just this guy, you know?

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
Leopard: First Impressions
by Mike Ash  

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:

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 a whole book full of them. It's available for iBooks and Kindle, plus a direct download in PDF and ePub format. It's also available in paper for the old-fashioned. Click here for more information.

Comments:

n[ate]vw at 2007-12-01 07:58:10:
>Properties are unexciting syntactic sugar

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.

Chris Ryland at 2007-12-01 08:34:44:
Nice post.

How is transparent animation broken? Do you have an example?

mikeash at 2007-12-01 09:15:33:
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:

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.

Ahruman at 2007-12-01 16:36:40:
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. :-)

mikeash at 2007-12-02 01:19:18:
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.


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.

Name:
Web site:
Comment:
Formatting: <i> <b> <blockquote> <code>. URLs are automatically hyperlinked.
Hosted at DigitalOcean.