3 ms·

That sounds even worse. Why should primitive types be treated as second-class entities that can only arise as private implementation details of a class? In any

That sounds even worse. Why should primitive types be treated as second-class entities that can only arise as private implementation details of a class? In any case, my original point still stands: (0) Dimension errors are really what one seeks to prevent by discouraging things like `double meters;`. (1) Making a separate class for each unit of measurement doesn't compose or scale well. Dimensional analysis is a fundamentally structural business, and this really calls for compile-time arithmetic with the exponents of primitive dimensions. But, of course, if your hammer is Java-shaped...

scotty79 10y ago
> Why should primitive types be treated as second-class entities that can only arise as private implementation details of a class? Because primitives are meaningless. String has no meaning. "Message" does. "Contact person" does and has conceptually nothing in common with a "Message". Why should they be both of type String? The real problem with primitive obsession is that it stifles software evolution. Suddenly Message needs to keep other data or have some methods associated with it. Every place where it was used is suddenly invalid because you need to go from String to class and inheriting from primitive is just silly if at all possible. That's what you want to prevent. It has almost nothing to do with units or dimensional analysis.
- catnaroek 10y ago
  > Because primitives are meaningless. That depends on your problem domain. If I'm implementing a library of data structures and algorithms (which I have to do, because most standard libraries are subpar on this front), then I definitely want to work with raw integers or sequences (but probably not strings - they should be just a special case of sequences). > "Message" does. "Contact person" does and has conceptually nothing in common with a "Message". No disagreement in this particular case. It's indeed best to have separate types for things on which different operations make sense. But, personally, I find it more tasteful to have little to no algorithmic logic at the level of business domain entities. Algorithms work on mathematically structured data.
  - sharpercoder 10y ago
    But math is a problem domain as well. I rather have specialized types to work with there as well, for above mentioned reasons (intention, documentation).

scotty79 10y ago

> Why should primitive types be treated as second-class entities that can only arise as private implementation details of a class? Because primitives are meaningless. String has no meaning. "Message" does. "Contact person" does and has conceptually nothing in common with a "Message". Why should they be both of type String? The real problem with primitive obsession is that it stifles software evolution. Suddenly Message needs to keep other data or have some methods associated with it. Every place where it was used is suddenly invalid because you need to go from String to class and inheriting from primitive is just silly if at all possible. That's what you want to prevent. It has almost nothing to do with units or dimensional analysis.

catnaroek 10y ago
> Because primitives are meaningless. That depends on your problem domain. If I'm implementing a library of data structures and algorithms (which I have to do, because most standard libraries are subpar on this front), then I definitely want to work with raw integers or sequences (but probably not strings - they should be just a special case of sequences). > "Message" does. "Contact person" does and has conceptually nothing in common with a "Message". No disagreement in this particular case. It's indeed best to have separate types for things on which different operations make sense. But, personally, I find it more tasteful to have little to no algorithmic logic at the level of business domain entities. Algorithms work on mathematically structured data.
- sharpercoder 10y ago
  But math is a problem domain as well. I rather have specialized types to work with there as well, for above mentioned reasons (intention, documentation).