Re: [boost] [spirit] Library naming and sub-libraries

Subject: Re: [boost] [spirit] Library naming and sub-libraries
From: Andrew Sutton (andrew.n.sutton_at_[hidden])
Date: 2009-01-03 10:52:21

>
> Look, I'm not arguing that the library name is everything you need to know
>>> about the library. I'm just saying that informative names really do help to
>>> find what you need.
>>>
>>
>> How about Boost.Any? For the uninitiated, that could contain smart
>> pointers. I look at the current names. Only a very few give me
>> the enough information to know what they are for. What is assign?
>> What is enable_if? What is parameter? asio? ref? variant? mpl?
>> units? optional? etc. I wouldn't know by just the names!
>>
>
> Some of them are quite telling (iostreams, variant, filesystem, datetime,
> threads, function, program_options, serialization, should I go on?). At
> least, more telling than Qi. And I repeat myself, the name does give a hint
> on the library purpose, and I find it useful.
>
> I'm not sure what exactly you are trying to convince me in. Is it that
> library names are irrelevant to their domain? Well, we could name libraries
> like GUIDs, at least we would have world-wide unique names. Do you think it
> would make life easier for users? Seriously, I'm not sure what we are
> arguing about.
>
>  If I was looking for a particular library in Boost. I'd look at
>> the categories. It's a shame that the current web interface lost
>> this very useful page:
>>
>>  http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category
>>
>
>
It can be many things, but it definitely isn't a library of smart pointers,
> is it? On the other hand, Boost.SmartPtr is most likely what I'm looking for
> - therefore I will put more attention to it (read the docs, for a start).
>
> Look, I'm not arguing that the library name is everything you need to know
> about the library. I'm just saying that informative names really do help to
> find what you need.

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.

Andrew Sutton
andrew.n.sutton_at_[hidden]