I’m playing with some design changes for MarsEdit’s main window, and thinking it will probably end up mimicking the classic “Mail source list utility bar” appearance, where a few small buttons appear beneath a source list at the left-hand side of the window.

With things in flux while I moved bits and pieces of the UI around, I was able to observe a pretty stellar example of how the visual placement of objects within a container can dramatically change the appearance of the container’s size. Consider these snapshots, taken from Mail and this experimental version of MarsEdit. Stare at the buttons on the Mail version (top), then at the buttons on the MarsEdit version. Which section is taller?

Answer? They’re exactly the same height. 23 pixels tall. The crowdedness of the MarsEdit version makes the whole section seem way shorter than it really is, while the Mail version has miles and miles of room to breathe.

It occurs to me that this illusion might not affect everybody the same way. To me the difference is stark, unless I start fixating on the blank part of the bar, when I can more easily accept they are the same size.

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.