Design Element
Comment on "The Year in Mac Development"
by Scott Stevenson — Jan 01
@Nick: I believe the source list first showed up in Tiger's version of Mail, which was developed alongside Tiger itself. As you say, the public API starts life as private API and is refined until it's ready for general consumption. Since there as been no major release since Tiger, I don't see an opportunity for Apple to release it.

To be honest, this may become a moot point shortly. We don't know what Leopard has in store yet.

@Matt: Treating an Objective-C object as a struct isn't the same thing as the properties system. Direct struct field access isn't evaluated at runtime (therefore can't be manipulated by Objective-C/KVC magic) and it's not future proof. If the Objective-C runtime changes to make field access a hard error, all of that breaks. If the pointer is null, the app crashes.

The whole point of properties is that they provide the syntactic conveniences of direct access while still properly abstracting things from the raw data structures and activating dynamic dispatch. From the caller's perspective, it's very similar to KVC, just without all the -valueForKeyPath:@"..." stuff wrapped around it.

In other words, this:
value = [object valueForKeyPath:@"item.thing.value"]; [object setValue:value forKeyPath:@"item.thing.value"];

Is roughly equivalent to this in most cases:
value = object.item.thing.value; object.item.thing.value = value;

I agree low-tech implementations are better when complexity doesn't buy you anything, but Apple can't pretend that the whole world revolves around C anymore. For better or worse, Ruby, Python, JavaScript and so on have changed how people see programming.

With this approach, they can meet in the middle on syntax and still take advantage of the fact that Objective-C is both compiled and dynamic. And just like garbage collection, you don't have to use the dot syntax it if you don't want to.

I don't know how serious the issue of mixing structs with objects actually is. There are a lot of things programmers could do to make Objective-C code look ridiculous (and some do), but typically sensible conventions win when good programmers are writing code. I don't know if the this/that/something example you gave would actually compile. It might, but I haven't tested it.
Back to "The Year in Mac Development"
Design Element

Copyright © Scott Stevenson 2004-2015