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