TITLE: A Few Good Abstractions AUTHOR: Eugene Wallingford DATE: May 17, 2005 8:31 AM DESC: Joel spends a lot of time telling us about the dangers of abstractions, but some of the problems he seeks to solve are best solved by ... an abstraction. ----- BODY: I just read Joel Spolsky's latest essay, Making Wrong Code Look Wrong. I'm all for Joel's goal of writing code that reveals the writer's intention, of making code transparent to the reader. And I'm sympathetic to his concerns about operator overloading in C++ and leaky abstractions. But the following paragraph exemplifies why I find his C-at-all-costs mentality somewhat uncomfortable:
If you read Simonyi's paper closely, what he was getting at was the same kind of naming convention as I used in my example above where we decided that us meant "unsafe string" and s meant "safe string". They're both of type string. The compiler won't help you if you assign one to the other and Intellisense won't tell you bupkis. But they are semantically different; they need to be interpreted differently and treated differently and some kind of conversion function will need to be called if you assign one to the other or you will have a runtime bug. If you're lucky.
Does anyone else think that Joel needs a really good abstraction here? If my program deals with two different kinds of string -- objects that are semantically different -- then I'd like to reflect that in more than a cryptic two-letter prefix. Classes may seem like overkill for these kinds of thing, but enums and Ada subtypes can be wonderful aids. Then, instead of relying solely on the programmer to read and interpret the prefixes, we could let our compilers and refactoring tools help us. Intention-revealing names are an important part of transparent code, but we should use languages and techniques that support our efforts, too. -----