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
>>> 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
-- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk