Leland Brown wrote:
I think restricting the library to "physical quantities" is a big mistake. You've put a _lot_ of effort into getting the metaprogramming right for his and we ought to try to re-use it wherever possible. I don't relish the idea of creating a parallel "electrotechnology system" framework that looks exactly like pqs but with powers of 2 and 10 (to do the conversions). Let's get it right in a single library.
Several reviewers have made comments to this effect. It seems there is a need in a variety of non-physics contexts as well for a general units conversion library.
However, IMHO, PQS is *not* a units library. Its purpose is to do dimensional analysis. For this reason (as well as a weaker one I mentioned in another followup post), I oppose the name "units" for the library. That would only add to the confusion. Units conversion is a necessary part of the library (or adjuct to it) in order to create the dimensional quantities, but the core purpose and utility of the library is its compile-time checking of dimensional formulas and enforced documentation of dimensions (as well as units).
The two go hand-in-hand. What good is a "units" library without dimensional analysis? All I'm saying is that we should not need to create multiple versions of pqs to handle different sets of units. Where does it stop? I want one for "electrotechnology." Someone else wants one for non-SI units. Someone gave an example of dimensioning fruits and vegetables. Do we really want separate frameworks for each of these uses? It should all be in one framework. I'm not saying everything needs to be implemented right now. Just that the flexibility needs to be there for _someone_ to do it. The assumption of powers-of-10 prefixes precludes that.
Perhaps, as Gerhard Wesp suggested in one of his posts (sorry, I don't know how to include a message reference):
I think that handling of dimensional quantities and conversion factors are orthogonal concepts and should be separated.
If there's a way to do this, perhaps the units conversion can be made more general and put into a separate library, and the dimensional analysis library can make use of it. But please, let's not lose sight of the great importance of a dimensional analysis library. Many users (though perhaps a minority) find this *very* useful.
As Andy has stated, the two are orthogonal in pqs, it's just that metaprogramming is used to encode the conversions in the type system, thereby saving runtime calculation by doing it at compile time. This is the correct approach, because for t1_quantity, all of the necessary information is known by the compiler. -Dave