View objects make bad keys. Views have state related to the screen: their frame, position in the view hierarchy, animation layers, etc. When you copy a view object, the copy won’t (always) be isEqual: to the original, because it’s not on the screen in exactly the same way.

Of course, this isn’t a complete list of every way key-copying can trip you up. But if you understand what copy means in Cocoa, and remember how NSDictionary works, you’ll be able to avoid or quickly solve any issues.

How to Document Such Behavior Better Than Apple Did

Given what we know about NSDictionary, what’s wrong with the following snippit from NSDictionary.h?

Answer: aKey needs to implement NSCopying, so it should be of type (id<NSCopying>) instead of type (id). That way, the header is self-documenting, and, if like most smart programmers, you’re using autocomplete to type out Cocoa’s long method names, the auto-completed template will be self-documenting too.

August 20, 2008

With every programming language/development environment I know of, you have to do extra work to make a string localizable. For example, errorMessage = NSLocalizedString(@"This is hard!",@"");
not simply,errorMessage = @"This is hard!";

And it’s not just extra work, it’s a ridiculous amount of work. E.g. to create an Objective-C string, you just put an @ in front of a standard C string. But to create a localized string, you have to surround your string in ()‘s, and prefix it with a seventeen character mixed-case function-name, and finally add an empty “note” for the translator. (Rarely, you may want to add a note for the translator, and it’s good that you can, but you should not be forced to write something when it is not necessary.)

There isn’t really an excuse for this; it’s just how languages have lazily evolved.

Non-localizable (“hardcoded”) strings are a huge issue, even though they are trivially simple for programmers to fix. The problem is that translators do not work with source code, they work with resource files. So when they find a “hardwired” string that must be changed in code, they tell a programmer to fix it. And that communication is slow and costly. Especially when you consider that good localizers are probably native to the place they are localizing for — meaning that having a real-time conversation involves at least one party staying up past 3AM.

I dream of a day where "this would be localized by default"; "and"("syntactic sugar for adding optional translator notes would be there too"); and creating C"literal C-strings" would be easy.

“Unicode support libraries” are doomed to institutionalized-failure, because they will never make it easier to do the right thing. It must be so easy to create a localizable program that you wouldn’t dream of doing anything else.