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