Andrey Semashev wrote:
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...
Hmmm. Why would we choose a funny name? I find it hard to parse that. It's either a) you are being sarcastic b) you think the names are funny and think that we chose funny names because we don't care about our users c) what else? This is getting nowhere. To me there are more important issues. This naming issue is a bike shed issue I would want to simply ignore.
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?).
These "yet to be released libraries" have been with us since 2006. There were presentations at BoostCon 07 and BoostCon 08. It's been in use and is slowly starting to gain a user-base. So far, I haven't heard any complaints related to the reasons you and Robert mention like wasting other people's time, difficulty in understanding, etc. Nor were there protests to change the names. If we change the names now, it would cause more confusion and destabilize the code more than the meager advantage it may provide. That said, I will discuss it with Hartmut and with the Spirit users. Let's see how it goes.
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.
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.
Traditionally, that's true. Have you seen a formal language like EBNF describe generation yet? But if you think outside the box, these really *are* two sides of the same coin. Should Boost.Serialization should be broken into two libraries, for example? Perhaps, but those sub-libraries are under Serialization. Ditto for IOStreams.
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.
I suggest you go back to the list archives and peruse the Phoenix (and perhaps also Fusion) review. These questions are discussed in depth there. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net