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

Subject: Re: [boost] Proposal: Add Loki Library's SafeFormat to Boost:
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-01-02 05:37:53

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.

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

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