Re: [boost] [Review][PQS] Physical QuantitiesSystemreview(May31through June 9)

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2006-06-04 07:17:39

>>> I dont follow what you are saying here. Do you mean that I should use 
>>> more
>>> meaningful variable names?
>>>
>> I mean that
>>    #include <boost/pqs/types/length.hpp>
>> should really cover current and future
>> length metrics.
>>
>> The "t1"s would be hard to maintain in legacy code
>
> You mean that :
>
> #include <boost/pqs/types/length.hpp>
>
> should bring in the (socalled) t1_quantity, t2_quantity for length?.
>
> Its worth thinking about, though I do have certain doubts about putting
> everything in one header. It would make life simpler though. The current
> hierarchy is noticeably too deep.
>

Yes. The "t1" is arbitrary symbol that doesn't make
much of sense. When someone wants to use the units
the include path should be intuitive

#include <boost/si_units/capacitance.hpp>

 _______________________________________________
>>>> 25. Naming: people may not like long names
>>>>    like boost:pqs:xyz.
>>>>
>>>>    Perhaps there could be a macro that,
>>>>    given a namespace (i.e. global) and common
>>>>    name prefix, will create all typedefs
>>>>    where the user likes them. Something as
>>>>
>>>>    BOOST_UNITS_DECLARE_ALL_IN(::, unit_)
>>>>
>>>>    and then "unit_m" would be meters.
>>>
>>> Maybe. but user can use namespace alias , typedef or using for preferred 
>>> set
>>> of
>>> units. Unless the current mechanism is unacceptable I am in favour of 
>>> not
>>> providing alternatives.
>>>
>> The macro could be generated. Hand-typing the typedefs
>> would not be the best past-time. There is also chance
>> that someone may want to replace existing a legacy
>> unit typedefs with the new library.
>
> I could remove all the named_quantities part of the library and leave it 
> to the
> user to deal with which sounds like what you are suggesting. That would
> certainly save me a lot of work. However from my own point of view ( as a 
> user)
> I am quite lazy and I like all this work to be done for me. I feel that 
> the
> current interface works reasonably well. A point that is remarkable about 
> the
> current library is that basically its a large database of value_types 
> rather
> than something to compose ones own types from.  In fact the format of the 
> naming
> convention for the named_quantity typedef  isnt well documented, but the
> ambition was that the interface (ie length::m) communicates better than 
> the
> class template t1_quantity<length,zero_unit,double> does.
>

Another possible solution: have one internal header with things like:

typedef .... BOOST_UNITS_CURRENT_PREFIX ## m; // meters

Then the header that user will include could be:

#define BOOST_UNITS_CURRENT_PREFIX boost::pqs::
#include "internal-header"
#undef BOOST_UNITS_CURRENT_PREFIX

> Apologies that I find it difficult to communicate what I am trying to say 
> here.
> I feel that the interface ( which you want to be able to customise) is the 
> most
> important part of the library in many ways. That is its most useful 
> feature and
> is what saves the user time and effort, assuming they understand the 
> 'feel' of
> it of course. The interface hides some rather messy details of the 
> t1_quantity,
> ( coherent/incoherent units etc etc) . Remove the
> interface and the user is exposed to all that which is not good AFAICS. 
> They
> then need to recreate their own interface.
>
The change would be from:

     boost::si_unit:m
to
    my_m

if people are too lazy to type or must obey different conventions.
Existing interface would be always present and documented.

It is not, however, showstopper in any case, just possible
convenience for minority of users.

/Pavel