Joel de Guzman wrote:
Robert Ramey wrote:
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.
Here are examples where time has been wasted. All of a sudden, one some platform the serialization library fails to build. After a time, an investigation reveals that the #include <boost/spiritsomefile> get redirected in some baroque non-obvious way to something like boost/spirit/class.. or something like that. OK - I'll just tweak the library so that it includes the "classic" targets directly. Now, the library won't build for borland compilers. Turns out that this compiler needs spirit 1.6x - which I have on my machine but the directory structure is different. To top it off, there isn't enough information - or its not sufficiently obvious to find - to conditionally include the right stuff. Now, it looks like spirit is going to be "upgraded" how will this effect the current code? No way to know. How much time have I wasted on this? I didn't keep track. Not that it matters since we're not apparently done yet. Here's a suggestion. for your latest/greatest, put in the namespace boost::spirit and in directory boost/sprit For your old version, with an incompatible API, put it in namespace boost::spririt_1_8 and directory boost/spririt_1_8. and for your older version put it in boost::spririt_1_6 and directory boost/spririt_1_6 And include a macro BOOST_SPIRIT_VERSION with the version string or number Leave the tests in the previous versions even though they are no longer being tested. This would be really helpful and I don't think it would create much work for you. Robert Ramey