Re: [boost] [spirit] Library naming and sub-libraries

Subject: Re: [boost] [spirit] Library naming and sub-libraries
From: Joel de Guzman (joel_at_[hidden])
Date: 2009-01-02 12:35:01

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