Re: [boost] Proposal: Add Loki Library's SafeFormat to Boost:

Subject: Re: [boost] Proposal: Add Loki Library's SafeFormat to Boost:
From: Joel de Guzman (joel_at_[hidden])
Date: 2009-01-02 08:20:15

Andrey Semashev wrote:
> Joel de Guzman wrote:
>> Andrey Semashev wrote:
>>> Robert Ramey wrote:
>>>> Hartmut Kaiser wrote:
>>>> The fact that names are in no way descriptive is another huge time
>>>> waster.
>>>
>>> I'd like to second that concern. I know, this is your library and you 
>>> are to decide how to name it, but all these words, like Spirit, Qi, 
>>> Proto or Karma, tell me nothing about what these things are for.
>>
>> So does Haskell, or Python, or Loki, Rails, or even Boost. But so
>> what? I don't understand the problem. It takes a few seconds to
>> know that Boost is (a set of) "free peer-reviewed portable C++
>> source libraries".
> 
> I disagree. Programming languages usually are difficult to describe in 
> one word that would outline its specific features. Although, Lisp and 
> Basic are quite descriptive even then.
> 
> Boost, Loki, etc. are library collections that help people in very 
> different domains, so it's difficult to come with descriptive names for 
> them, too. However, IIRC, Andrei has outlined rationale for his library 
> name in his book.

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.

> But we are talking about Boost components that have a well defined usage 
> domain and a set of tasks they are intended to help in. Function, Bind, 
> Variant, Filesystem, DateTime - when I see these names I already grasp 
> what sort of things they are, and I don't have to dig into docs for 
> that. When I see Spirit - I don't. BTW, on the library requirements 
> page, there's a recommendation to use meaningful names for C++ symbols. 
> I don't see why it doesn't apply to the library names, too.
> 
> In connection to other posts in this thread: no, I don't think that 
> Spirit is a library with a difficult to describe usage domain. It's a 
> parsing library and let's leave it at that. 

Are you suggesting that Spirit be renamed to Boost Parsing Library?
Sorry, but no thanks.

> 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 is a Spirit sub-library. Parsing and generation are two sides of
the same coin.

> 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.

> 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?

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net