Joel de Guzman wrote:
You can disagree as much as you want. You can rationalize as much as you want. Well, programmers tend to do so. As far as I am concerned,
a
name is a name and I, as author, reserve the right to naming my work.
Now that's a very "constructive" approach, I must say. Yes, you may name it as you like, but if the name is nothing but a funny word to you, you just push away users of your library. Unless you don't care about that, that is...
Spirit got well known all over the world even while being named with the 'funny' name. IMHO, this whole issue mainly is a matter of taste, so I doubt we'll find any consensus.
Are you suggesting that Spirit be renamed to Boost Parsing Library? Sorry, but no thanks.
I understand that it's too late to rename the library now. However, I'd like to ask to reconsider naming of yet to be released libraries, like Karma or Qi (or what was it?).
Just read the first paragraphs of the 'Introduction' in the docs and you'll know. That's something you'll have to do anyways, even if the library has a 'functional' name.
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost.
I disagree. Karma was never advertized as a top-level Boost Library.
It should, IMO.
Think about this again and you'll see Joel's point. Karma is based on the idea, that a grammar usable to parse an input sequence may as well be used to generate the very same sequence in the output. Qi and Karma use exactly the same description of the (expected/generated) format - a grammar.
It is a Spirit sub-library. Parsing and generation are two sides of the same coin.
These tasks are the opposite. I don't see why they should be mixed in a single library.
For the same reason as Boost.Serialization consists out of two parts: serialization and de-serialization.
The situation with so-called sub-libraries, IMHO, is a bad thing to allow in Boost. This turns libraries like Spirit into a playground where actually live several libraries with totally different classes of tasks being solved. What's worse, these libraries don't get reviewed (which
Phoenix and Fusion got reviewed. They were once sub-libraries under Spirit. Proto got reviewed. It was once a sub-library under Xpressive.
How long did they exist as parts of Spirit? Were they approved to be included as parts of Spirit and/or recommended/allowed to be used independently? Why would Spirit contain a duplicate for Lambda and how they can (or should they?) coexist gracefully in the user's code? Which one should be used by default? These questions may sound silly to you, but I recently happened to write an article about Boost libraries, and such questions took a lot of time to answer. I believe, every developer exploring Boost will stumble on such questions sooner or later.
All these question do not have any connection to the naming issue related to which you're trying to make a point.
may be a tempting reason to add such libraries), they duplicate other existing libraries in Boost (which confuse users), and they honor further duplication in the upcoming libraries (which wastes time of these libraries' developers).
Which upcoming libraries are you referrring to? Could you be more specific?
I was saying in general. The current state of code in the repository introduces the "common practice" which can be followed by the new library authors.
Boost is a very dynamic collection of libraries. And the existing libraries provide an excellent playground for the library authors to improve what's there and to add new capabilities. It was a Boost guideline from the very beginning, that a library is reviewed once and afterwards the authors are free to develop new versions of this library without further review. This approach has lead to the development of Proto (former part of Xpressive) and Phoenix and Fusion (former parts of Spirit). IHMO, this is a very productive way of gaining new insights and developing useful libraries. Regards Hartmut