Re: [boost] [Review] Quantitative Units library review begins today, March 26

From: Eric Lemings (lemings_at_[hidden])
Date: 2007-03-28 12:19:13

Greetings,

I've only begun to review the proposal in detail so the following
comments apply to the proposal as a whole.

"What is your evaluation of the design?"

I was glad to see that the vocabulary of the program domain as defined
by the authors aligned, more or less, with my own terminology.  Speaking
the same language is especially essential for this particular subject.

The goals of the overall design also seem to align with what I would
like to see in a Boost Units library.  After lots of trial and error
with my own design and implementations however, I believe the scope of
any library accepted into Boost to fill the "units of measurement"
and/or "dimensional analysis" role must be limited.  The following
paragraphs outline this scope.  Apologies if I ramble a bit.

Undoubtedly, the scope of this library should include the dimensional
analysis framework which defines the fundamental types/metatypes (e.g.
dimension, unit, quantity), their semantics, and their operations.  It
should also include only the most common dimensions such as the physical
dimensions (time, length, mass, etc.) and allow, at least, other
universal
dimensions (e.g. currency).  Other, more specialized dimensions should
be defined elsewhere.

The scope should not include any facilities for input and output.  It
should also not prevent such support however.  (Input and output of
units and measures can be handled by extending C++ locales with new
facets.  C++ locales already deal with I/O of time and money.  More
about internalization and localization below.)

The scope should not classify units of measurement into exclusionary
systems.  True, many programs/programmers will have restrictions that
prevent/exclude use of any units of measurement outside a well-known
set of units but the other extreme is also quite possible.  A program
may allow arithmetic/conversions between any and all units known to the
development/operating environment.  In such cases, the programmer is not
concerned in the least with systems of units and classification of
units into systems becomes totally irrelevant (and impossible for many
older and rarer units of measure).  Therefore, if constraining units
into discrete systems is a desired objective, it should be the
responsibility of the program rather than the library.

Whether the scope should include a particuar system of units (e.g. SI
units, Imperial units) is debatable.  Personally, I believe each system
of units should be treated much the same way C++ currently treats
locales.  The library may contain, even mandate, a "default" set of
units (e.g. SI) but including even the most common modern units is
beyond the scope of the library.  (Which units are modern?  Which units
are common?)  Each system of units can therefore be defined separately
as an extension to the underlying framework.

I'll post more specific review comments about the proposal later.

Thanks,
Eric.