mikeash.com pyblog/leopard-first-impressions.html comments

mikeash - 2007-12-02 01:19:18

Sun, 02 Dec 2007 01:19:18 GMT

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.

Ahruman - 2007-12-01 16:36:40

Sat, 01 Dec 2007 16:36:40 GMT

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

Sat, 01 Dec 2007 09:15:33 GMT

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.

Chris Ryland - 2007-12-01 08:34:44

Sat, 01 Dec 2007 08:34:44 GMT

Nice post.

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

n[ate]vw - 2007-12-01 07:58:10

Sat, 01 Dec 2007 07:58:10 GMT

>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.