Comment by fusiongyro | Hacker News Reader

Comment by fusiongyro | Hacker News Reader

Parent Full thread

It's the same effort to the machine, not the developer. If the objects manage their own units, you can just use them naively and let them handle their conversions during arithmetic if they need it. You don't need to write the code for conversion explicitly anywhere outside the class. This is a material advantage of object-oriented programming, consolidating the knowledge about one aspect of your program to the right place to deal with it and keeping it out of the rest of the codebase.

How's your standard units solution going to work when the users consider their input units to be part of the data? Are you going to store their units alongside the converted units and convert them back whenever you want to display? If so, you've just replaced Matt's example problem with an identical problem. This is a clue that you have insufficient abstraction: a small change of requirements can force a lot of code to be written across your application. And don't assume you can dictate units to your users, there are plenty of situations in which the users and their units are vastly more important than the programmer's time and ease.

>How's your standard units solution going to work when the users consider their input units to be part of the data? Are you going to store their units alongside the converted units and convert them back whenever you want to display? If so, you've just replaced Matt's example problem with an identical problem.

That's kind of my point. The problem isn't primitives. The problem exists no matter what you do: you still need to do conversions based on the user's inputs and the program's output.

>How's your standard units solution going to work when the users consider their input units to be part of the data?

In which case, the user will be inputting the unit and the amount, and telling me what units they want to use as an output. Internally, once this is passed from the interface, you convert the unit to your standardized unit. Similarly, when printing it out, you convert it back to the user's selected unit. Again, this is simply calling the convert function when the data is initialized, and calling it again when it's printed.

OO does not magically solve this problem. If you're storing it in the user's selected type, then every time any function accesses the data, they're either going to have to code around the different types, or call convert() to get it into the type they want. So from a developer's perspective, this is the difference from 2 guaranteed conversions(at input and output time), versus conversions whenever the data is accessed, and at output time.

>And don't assume you can dictate units to your users, there are plenty of situations in which the users and their units are vastly more important than the programmer's time and ease.

Actually, as a developer, you DO dictate units to your users if you're doing anything more than just storing and regurgitating the data. If the user selects a salbartifast unit, then you absolutely need to know how it related to grams, BU, or whatever else you're using in order to use it in any of your calculations.

Actually, Matt and I are are both independently saying that OO does magically solve this, because it has. It doesn't look like either of us have made it clear enough for you that this is the case, but it isn't a matter of debate: the codebase I work on at work has greatly benefited from it, and this fact isn't really vulnerable to your conception of why it must be the same amount of work. You're not seeing that it isn't. This is a communication problem.

I think using OO properly would solve this. You have a carbs class that you can instantiate (and update) with two arguments: value and units. This gets converted into whatever representation you use internally, and then whenever you want to access the value, you would do carbs.grams() or carbs.breadUnits() or whatever other units are needed. I don't see a need for a convert() method (maybe as a static function if you want to be able to convert units without instantiating a carbs object, but now we're moving away from the discussion at hand).

Excellent point.

If they "consider their input units to be part of the data", by which I assume you mean something like "if I use carbs here, and BU there, keep it that way", then you need to store the unit regardless. In that case, since value is always paired with a unit and both are variable, I totally agree. Encapsulate. Two related values that cannot meaningfully be separated should be treated as a single object.

But I've never seen a system like that for something like carb counting - it's always normalized, and everything is displayed in a single unit at a time, maybe changeable by user preference. Maybe the problem is that so far nobody has built such a system. Maybe it's that doing so means more complex SQL queries and larger indexes, because you need to consider two fields instead of one when summing / averaging / etc. Maybe it's because users don't want it.

The argument for ints in this case is also an argument that you should only show a single unit at a time. So long as that's true, the encapsulation argument carries a lot less weight - at that point, I'm not sure which I'd choose. The benefits are a lot less real, though.

In my case (astronomy) we have to store the units regardless and they're always together, but in light of changing requirements, I'm not sure it would be overkill to make this explicit up-front even if there weren't explicit requirements to do so.

Oh. You could have mentioned that. :P

Astronomy is the one field where it makes perfect sense to store the units, because basically nobody agrees on what the standard should be. My professor in college joked that if you had 5 astronomers in the room, you'd get 10 different sets of "standard" units.

Reply on news.ycombinator.com