4 ms·

98% of this article is a discussion of the use of strings in HTTP headers. The last 4 or 5 sentences tries to generalize the conclusion to strings at large. I

98% of this article is a discussion of the use of strings in HTTP headers. The last 4 or 5 sentences tries to generalize the conclusion to strings at large. I feel a bit misled by the title. It would have been nice to have 3 or 4 examples, and a much larger argument that strings in general should be abstract. However, even with all of this underpinning, it doesn't work. This is like an argument against integers because integers can express so many things: age, number of arms, days of the year, and so forth. Base types can cover a lot of things! Film at eleven. The discussion should have been about proper API construction, and when to subclass. Or even particular problems with HTTP Header APIs in Java -- I really liked that part. If the author had stuck with it, I wouldn't have felt a bit bamboozled.

dmethvin 13y ago
> This is like an argument against integers because integers can express so many things: age, number of arms, days of the year, and so forth. Yes, and just like the strings case it shows how useless most primitive types are from a program correctness and documentation standpoint. Languages like C++ and Java encourage programmers to treat them as mystical bags-of-holding and forget about their limitations or relation to the data being processed.
derleth 13y ago
> This is like an argument against integers because integers can express so many things: age, number of arms, days of the year, and so forth. And each of those uses should be given its own type, and the compiler should refuse to compile if you pass setPersonAge() a value of type ArmNumber even if the relevant types are both implemented as 32-bit half-words at the machine level. If you are writing systems software or encryption software and need to care about machine-level details, that should be encoded into the type system as well. The semantic meaning of a type should be decoupled from its machine representation; for example, the type PersonAge could be implemented as a string in part of the program and still be the same type, because the compiler can handle auto-conversion like that no problem but the semantics of the value haven't changed. Or, at least, that's one way to look at types.

dmethvin 13y ago

> This is like an argument against integers because integers can express so many things: age, number of arms, days of the year, and so forth. Yes, and just like the strings case it shows how useless most primitive types are from a program correctness and documentation standpoint. Languages like C++ and Java encourage programmers to treat them as mystical bags-of-holding and forget about their limitations or relation to the data being processed.

derleth 13y ago

> This is like an argument against integers because integers can express so many things: age, number of arms, days of the year, and so forth. And each of those uses should be given its own type, and the compiler should refuse to compile if you pass setPersonAge() a value of type ArmNumber even if the relevant types are both implemented as 32-bit half-words at the machine level. If you are writing systems software or encryption software and need to care about machine-level details, that should be encoded into the type system as well. The semantic meaning of a type should be decoupled from its machine representation; for example, the type PersonAge could be implemented as a string in part of the program and still be the same type, because the compiler can handle auto-conversion like that no problem but the semantics of the value haven't changed. Or, at least, that's one way to look at types.