#define KVC(X) [NSString stringWithUTF8String: #X ]

KVC(foo.bar.quux) yields that as an NSString. Replace the stringWithUTF8String: selector with stringWithCString:encoding: and the appropriate encoding at your leisure. It’s a shame you can’t bolt @ and the stringified result together with ## (it bums out), and a shame you can’t define it as @kvc(). Oh well.

theValue = [theRecord objectForKey:[aTableColumn identifier]];

Rather than using a dictionary as the model object, you could use KVC to access the properties of any instance:

theValue = [theRecord valueForKey:[aTableColumn identifier]];

There’s no way for the compiler to determine that the identifier will be a valid key.

Moreover:

Chuck wrote:
* Selectors have no analogue to @”fanController.arrangedObjects.favoriteBand.name”.

Indeed. Key-value coding includes key *paths*, not just keys. This offers considerable power, flexibility, and economy.

* I don’t really think KVC is analogous to selectors. There is a fixed, finite set of selectors,

This isn’t really true. You can create as many selectors as you want at runtime; there is no need for there to be a corresponding implementation (as so many people discover when they misspell a selector name…).

mmalc

You could create some NSKey type that is initialized with a string and functionally identical to a string, but I really don’t see how that’s so useful. I mean, in all honesty, have you ever lost track of the meaning of a KVC string in a way that a different but completely equivalent type would help?

Maybe I’m shortsighted or just not understanding, but it seems to me that this would just lead to slightly more code and make the type system slightly more complicated, neither of which I consider to be a very good thing.

Properties and KVC are orthogonal technologies.

Going by what’s written at http://developer.apple.com/leopard/overview/tools.html, properties provide a means to declare explicitly the semantics of a “member” (I’m avoiding simply rewriting “property” — strictly it looks like a declared property need not be backed by an ivar), and (if you wish) to synthesise the corresponding accessor methods.

You could therefore use properties independently of KVC, or you could use KVC to access properties.

mmalc

This is simply not true. I don’t remember exactly when KVC first appeared, but I think it was around 1994, perhaps with EOF.

* The selector thing came from Objective-C itself, and its basic framework of classes, when it still had Object as root class instead of the NSObject Apple gave us.

NSObject appeared in Foundation in about 1993…

* When Apple made Cocoa (well, actually when NeXTStep made Cocoa)

… the company “NeXT” developed OPENSTEP…

mmalc

1. Conceptually, the way you use KVC is very similar to the way you use a dictionary. I don’t know for sure if that’s a coincidence but I doubt it.

2. There are a number of sitatuation where you’d want to iterate through a list of keys that aren’t literally typed in code. In those situations, the keycode bit falls apart somewhat.

In my opinion, one of the major benefits of Objective-C is the simplicity of the syntax. I don’t know if the advantages justify the additional learning cost for those who are coming to the language for the first time. It strikes me as a bit too cryptic.

As for the lack of compile time checking, well, IMHO, that’s why unit testing is so popular nowadays, as a replacement for static variables.

I have a somewhat different opinion of this issue. I like it very much.

I love to be able to make use of this sort of thing in my code. It may stem from my experience as a Python developer where objects are explicitly dictionaries and can be accessed either by string (foo["x"]) or as a property (foo.x). Being able to select object fields in this way at runtime brings huge expressive power and flexibilty. Look at the way that parameters are specified to Core Image filters for example. It would be much harder to interface with these without KVC.

Admitiedly, there is a cost to this. If you don’t want to use it with your own objects why not just use foo = [myObject foo] and [myObject setFoo: foo] instead. It’s cleaner syntax than something like @keycode() or kMySyntaxForKeySomething, at least in my opinion. The KVC methods call these setters anyway, do they not?

Cheers,
Paul

Regards,
Pierre