Andy Little wrote:
I would hope that a general purpose physical quantities lib would deal with units, even if you dont use anything but the base units. The Mars lander crash and all that. IOW you need to be explicit about what units you are using.
In my view, a dimension library has to exist independently of any units library. It is a separate and smaller concept. I should stand on its own. This will make it a) much easier and faster to come to consensus b) much easier develop and test. c) immediatly usefull. Lots of applications would find it useful even in the absense of a units library. d) not permit applications that use only this functionality to not be dependent on anything else. e) someday a units library will be built that uses this. Some people won't like it for on reason or another. If dimensions are a separate library - this won't be a problem as they can use their own version of units.
Still, as I said, agreement couldn't be achieved last time round on pretty much anything,
So lets try to agree on less - a dimensions library.
This seems to be a pessimistic view of what went on IMO. Is it not up to the librray designed to come up with a solution based on the discussions. I incorporated some things from these discussions into pqs. However I have always had a very specific view of what I want from a physical_quantities library, which has naturally had a major influence on the design.
Ahhhh - here is the rub. Is the library designers job to satisfy his "customers" or produce the most elegant, complete and useful package as he sees it. This is a very hard question. The main reason that boost libraries are of superior quality is that they come closest to reconciling these conflicting propositions. Libraries are develope by one or two people. This maintains a logical cohesiveness and elegance which is essential to a good library. On the other hand, they have to satisfy a large number of different "users". Fortunately, most users are focused on features though sometime implementation issues are important. So the appropriate attitude to be successful in this endeavor is a) Make a list of all the features it going to need to get accepted. b) Start making your library c) Realize that the job is too big to get done before its obsolete d) Divide your library in to smaller pieces that are useful in their own right e) Pick a piece f) go back to b This whole thing of trying to satify everyone and still keep the thing from becomming a microsoft-like API is a huge challange - actually much harder than writing and proving the code and manual (though that is way harder than it looks !!!!)
Though if there was to be a boost version, unfortunately this would need to be thrashed out. And that is the problem. It is a big project. I would ideally like to 'boostify' pqs but dont have time currently.
Basically, I believe that in software design, as in most other design edeavors, less is more.
However Robert Rameys idea to do the dimensional anlysis library alone seems good, as it is less contentious and surely would not be too much work.
"would not be too much work" - LOL so it would seem. add in the documentation, tests, bjam hassle, varying compilers (add in a lot for this). even this is going to be a lot of work If this could be done a) we would have something useful b) people would have something to use for experiments on units. Issues of money, etc could be experimented with independently. This would be very helpful in a future discussion of units as we would have more real data and wouldn't have to rely so much on speculation. c) it has a better chance of getting accepted. d) This would add a lot to the writers resume - thereby making it easier justify the time invested - which is still going to be alot. Perhaps this could be used to flog the development of a rationals library. Another thing we sorely need. Robert Ramey