on Thu Jan 01 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
Robert Ramey wrote:
Hartmut Kaiser wrote:
You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have problems using Spirit.Karma either. Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster.
Just curious. How much time did you waste before you realize that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
True, but once you learn that, if there are 4-5 sublibraries that also have non-mnemonic names, it does start to look pretty confusing.
Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review?
Where is this custom/rules and when did this it start to apply?
There are no such rules. There's nothing wrong with extending the functionality of a library. Obviously, tacking the functionality of the filesystem library onto Boost.Python wouldn't make sense, but I think parsing and generation may be a bit more related than that ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com