Subject: Re: [boost] [spirit] Library naming and sub-libraries (was: Proposal: Add Loki Library's SafeFormat to Boost:)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-01-02 09:35:37
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,
> 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?).
>> 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
>> 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.
>> 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
I was saying in general. The current state of code in the repository
introduces the "common practice" which can be followed by the new