Re: [boost] mcs::units informal review request

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-01-20 13:23:19

Hi Yuval,

> I'm not sure about that. You had two ideas, the first was to forward
> everything to the value_type, so you'll have a us_dollar value_type,
> etc. I thing it's not convenient. Most users will find something like
>
> quantity<currency/*, default to double*/> q1(1500.0 * us_dollar);
>
> makes more sense than
>
> quantity<currency, us_dollar> q1(1500.0);
>
> It certainly fits the rest of the library better, IMO. More than that,

Maybe - for me, it makes more sense to modify the value_type in this  
way,
but this was just an off-the-cuff example of how one could accomplish  
time-
varying currency conversions with compile-time dimension checking in the
simplest (from the ease of implementation standpoint) way. I'm not  
sure I
agree that using a double precision value_type fits the rest of the  
library
better, though - I have spent a significant amount of time and effort  
to get
the library to gracefully and correctly handle any value_type that  
models
the necessary concepts, so it should be value_type agnostic as much as
possible.

> the second idea of extending the SI system pretty much, AFAIU, forces
> the value_type to *not* be anything like us_dollar - it should fit
> length and mass to!

This was presented as an option for convenience; you certainly don't  
have
to extend the SI system. But you may be right; if we're mixing  
physical units
and currency units, you may need to implement specific currency  
systems and
the conversions between them...

> So I believe it boils down to providing a runtime-changeable  
> conversion
> ratios for some units (currency), in addition to the currently fixed
> ratios for other units (physics). Whether or not you want to  
> support it,
> is a completely different matter...

You can do this already; it requires more work, because the  
conversion_helper
class (in conversion.hpp) needs to be specialized to work with  
currency systems
to accommodate the time-varying conversion factor.

That all being said, I personally don't feel that dealing with  
currencies (among a
number of other specialized use cases that have been proposed along  
the way
during the discussions of this domain) is a reasonable expectation  
for this library
to support out of the box; I have tried to make it flexible enough
to deal with a wide range of potential applications, but for those  
applications that
lie outside standard dimensional/analysis and units, I expect that  
users will use
this library as a foundation for their specific application.

Matthias