Andrew Sutton wrote:
Obviously, having a simple, denotative name for a library is a good thing, but it's only really effective when the name can succinctly describe the features and functionality of the library. It's also easier, when those features are limited to a few well-known abstractions like FileSystem, ProgramOptions, Graph, etc. This arguably isn't the case for Joel's work. The breadth of abstractions represented by those libraries (DSELs, Parsing, Generating, etc.) aren't necessarily best described by a single term. In such cases, it's probably better to pick a neutral name (Spirit, for example) than to pick one that could be misrepresentative or misleading.
I think the crux of the problem is not really the name of the library, but the ability to associate a library with a task. I think that Joel is right that it's a presentation issue.
The documentation index is just a flat listing of libraries organized alphabetically, which is kind of an arbitrary presentation and not especially conducive to this kind of task. The category listing is substantially more useful in these regards. I would argue for moving this to the top-level documentation page or providing a very obvious link to it.
Perhaps there are even better presentations for the breadth and scope of Boost libraries.
Thank you, Andrew. That is a very good and effective explanation. I am not against "descriptive" names. It can be good, especially for small, specific libraries, in some cases, as small as a single class, surrounded perhaps by a few support classes. That is not the case for Spirit. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net