Fraser Speirs recently tweeted some comments about strings in code:

“I think that I particularly hate strings in code that have programmatic meaning. I’m looking at you, KVC. And you, KVO.”

Reading this was one of those “yeah, that sucks!” moments, and it got me thinking about how the situation might be improved. The problem isn’t that strings are used to drive the logical flow of an application – this is nothing new. Since long before KVC (Key Value Coding) and KVO (Key Value Observing) came along, Cocoa has employed data-driven techniques for dictating logical flow in an application.

Consider Objective-C selectors. These are essentially “key value coded methods.” A selector is conceptually a string, so much so that Objective C offers a shorthand for creating selectors directly from text in your code:

SEL mySelector = @selector(doSomething:);

Apple even recognizes the desire to create selectors dynamically at runtime, and offers the NSSelectorFromString.

A great thing about selectors is that they’re only conceptually strings. The “SEL” data type is defined as an opaque data structure pointer. If you examine the memory of the structure (as of 10.4) you’ll see that it looks quite a lot like a string, which is handy for debugging, but it’s not guaranteed to be a string.

The opaque “obstruction” Apple has inserted between the conceptual and implementation levels mean two things:

1. Apple can change the implementation at any time to something that suits the system better.
2. Compilers can do first-class type checking on methods and functions that expect selector arguments.

Compare the selector situation with its much younger sibling, who seems to have been born in a hurry and without as much planning:

id myValue = [myObject valueForKey:@"hello"];

In contrast to selectors, where semantic meaning is locked into the explicit SEL data type, here we must derive meaning from the context of the constant string data. We only know that “hello” is a key (or we hope it is) because it is preceded by a “valueForKey:” method signature. It would have been a bit more cumbersome for Apple and developers if they’d defined a “KeyCode” type and required it in all key value coding and observing method parameters:

id myValue = [myObject valueForKey:@keycode(hello)];

But suddenly the string itself has a lot more meaning. You might argue that in this example, the problem is the same, but there’s just more context to surround the literal string. That’s kind of true, but with a true compiler type the meaning sticks with the variable long after it’s typed or viewed in the code. Methods could dynamically distinguish plain strings from coding strings, a compiler could produce warnings based on semantic knowledge of keys (“that string doesn’t conform to key coding syntax”), and runtime statistics could be gathered about the number of keys that are used by your application (whatever that is worth).

I haven’t really thought this through too far, but I’m curious why Apple chose not to mimic their own treatment of selectors when it came time to base another critical technology on conceptual strings. I wonder if a “strongly typed” set of key value coding methods as a wrapper on Foundation’s methods would prove useful in my projects, or be a misguided waste of time. What do you think?

If you’re lucky, you only get to say that phrase in a non-metaphorical, self-referential way once in your life. We just arrived home in Boston after a lovely two weeks in England. We visited London substantially, York briefly, and then Oxford quite substantially. My beautiful bride was an exchange student at Oxford around 10 years ago, and we’ve visited as a couple once before, and both love it. So it made a natural destination for our honeymoon. We had a great time discovering many facets of the city that even she, having lived there for a year, hadn’t discovered. “I can’t believe I never knew about this!” was the constant refrain. Great city.

I’m catching up on photos and such, which our friends were awesome enough to take and which I didn’t have time to review while away. My girlfriend wife has been giving me a hard time for two weeks because I apparently latched onto the English-ism “and such” in a big way. It just melded into my brain like it had been there forever, and I can’t think of myself using any other construct to express the idea of “and stuff, and so on, and whatzeyhoozey, etc., etc.”

Some of the photos our friends snapped were brilliant, especially one by our friend Wendy, which captures me in an excited state the night before the wedding. We had just finished an awesome dinner at Les Zygomates in Boston, which my parents were generous enough to host for us, and had gone out for a brief meeting with out-of-town friends at a nerd-compatible bar in Cambridge (near MIT) called The Miracle of Science. The presence of distant friends (many from SF, DC, and elsewhere) and the fact that the menu is organized in a table of elements format got me pretty excited (not to mention getting married to the most beautiful, thoughtful, intelligent woman on earth!), so I thought it was a good opportunity to express my thoughts in lolspeak:

The phrase “The Honeymoon Is Over” seems to have negative connotations in common language, but it’s a happy time for me. We just had a killer (if exhausting!) holiday in England, and now we get to settle back into our normal lives, except as a happily married couple. I’m reclaiming “The Honeymoon Is Over” as an enunciation of joy! Let’s get on with this rad life. Summer is nearly here, and we’ve got tons of work and play to do.

This year’s C4 conference, C4[1], is now open for registration. I had a blast as an attendee last year, and will have even more fun this year as a participating speaker!

PS It’s raining in Oxford, UK.

Still getting used to feeling the ring on my finger!

Chrissa and I were married yesterday in Lincoln, MA. Everything went really well, and the weather even turned out perfectly. Really couldn’t have asked for a better day.

It was great to turn the computer back on today and find not only a number of thoughtful emails, but scattered – well – wishing from some of my Mac developer colleagues. Thanks, guys! We were both touched by these gestures.

Probably won’t be posting much if at all over the next couple weeks. It’s been a very happy May, and now it’s going to be a very relaxing May.