Re: [boost] Interest in dimension/unit-checking library?

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-20 15:05:42

On 10/20/05, Deane Yang <deane_yang_at_[hidden]> wrote:

> I'm not arguing conceptual matters. Yes, I know adding lengths in inches
> to lengths in meters makes sense. But is it good, clean code?

I don't see why not. Nothing bad happens from allowing the conversion and it
prevents users from having to do it explicitly.

On 10/20/05, Deane Yang <deane_yang_at_[hidden]> wrote:

> In some sense, I consider this to be analogous to the difference between
> the strong type checking of C++ and the "anything goes" approach of,
> say, Perl. Somehow, for me, automatic unit conversion seems like a good
> fit with Perl but not with C++.

I'd say it's much more analogous to conversions in C++ from a short unsigned
int to an unsigned int being implicit. You don't lose any information in the
conversion and the conversion makes perfectly logical sense. Forcing users
to always be explicit is just making them write more unecessary code.

On 10/20/05, Deane Yang <deane_yang_at_[hidden]> wrote:

> I'm looking for an example of software design, not a toy textbook problem.

They are one and the same. Such an example can occur in code in a physics
simulation, for example, or anything else.

On 10/20/05, Deane Yang <deane_yang_at_[hidden]> wrote:

> But why? The underlying concepts of vector and point quantities apply
> just as well to my needs as it does to yours. The only difference is
> that you want to define a certain collection of dimensions, and I want
> to use a different collection. What's the difference?

Because vectors, points, and scalars are concepts which all exist at the
level of abstraction of a units library. The problems you describe exist at
a higher-level in code and have absolutely nothing to do with units of
different types in the same dimension, and really don't have anything to do
with units at all. I'm not certain why you aren't seeing this. Again, the
"problems" you describe occur even if you are using units of the SAME unit
type in two different locations, not just if they are of a different unit
type. Such problems exists even if you aren't using units at all. The only
reason you want operations disallowed between them in your particular
project is because the units are being used as details encapsulated in
different high-level concepts which only exists in your code. This type of
relationship is one that can only be expressed in your code. Forcing people
to always explicitly convert doesn't solve even this type of problem,
either. All it does is provide an artificial guard in your specific
high-level code through an entirely unrelated and illogical restriction put
in low-level code.

The reason you don't want years to be convertible to months has nothing to
do with them being of different unit types, it's because in your particular
project, you are using months and years as implementation details of two
different concepts that are not interchangeable. Those concepts could just
as easily both be represented in months and it would not change the fact
that you shouldn't add them together. As I said before, the reason why you
can't add them is because of a reason specific to your project and is
entirely unrelated to the units you are using. It is your responsibility to
provide that abstraction through encapsulation or by other means as it is a
restriction which exists at a higher level in code which doesn't even exist
in a units library. Forcing all explicit conversions only happens to
somewhat hide your particular type of "problem" in the case where those two
different concepts happen to also be represented by different units in the
same classification.

--
-Matt Calabrese