Subject: Re: [boost] [spirit] Library naming and sub-libraries (was: Proposal: Add Loki Library's SafeFormat to Boost:)
From: dan marsden (danmarsden_at_[hidden])
Date: 2009-01-02 12:13: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...
I'm sure everybody knows what Boost is? Are we considering renaming to
"Peer Reviewed Formative C++ Library Collection". Sorry if that's a slightly
silly example, but we cope with names such as Google, Boost, Spirit, Qi, Karma
etc. every day, it takes very little time to get used to them. The more
explicit names aren't always more helpful, renaming Fusion to "heterogeneous
container library" would IMO be a backward step for example. IMO library
authors should be left to pick the names, and Boost should not waste valuable
time over analyzing them.
>>> 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.
Precisely because, as you say they are opposite (dual) to each other,
and so present a good opportunity to address some missing symmetry in
previous versions of spirit.
I personally believe we should lean towards allowing authors creative
freedom, even if they do grow the scope of their libraries. It's difficult
enough for Boost to recruit sufficient high quality developers to produce
libraries the community need.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk