Re: [boost] [website] Proposal for new page - Libraries By Type

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-22 10:51:58

Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:

> David Abrahams writes:
>>>> * Class definition utilities
>>>>
>>>>     operators, noncopyable, base_from_member, compressed_pair
>>>
>>> Wouldn't you like to have Iterators library here well?
>>
>> Not particularly.  I might look here for iterator definition tools
>> but I'd also be inclined to look in a category for stuff related to
>> the standard library.
>
> Well, yeah, but do we really want to pretened that the library doesn't
> fit here when it clearly does, and make the user with whom the
> category "clicked" go rounds just because she will probably be willing
> to?

Yeah, I sorta do.  It fits here about as well as oil paints belong in
a category called "things that come in colors."  Yeah, it is accurate,
but everything else in the category is completely general-purpose, and
this one has a very specific purpose.  If someone else had written the
library I would have no problem allowing them to put it in as many
categories as they wanted, but my sense is that the library and its
users will be best served by putting it in one category that's closely
associated with its purpose.

>>>> * Standard Library Enhancements - libraries that make the standard C++
>>>>   library easier and safer to use or extend its capabilities in
>>>>   evolutionary ways.  Many relieve frustrations commonly encountered
>>>>   when using the standard library (see also Functional Programming)
>>>>
>>>>     IO: io state saver, iostreams, format
>>>
>>> What about Serialization?
>>
>> Yeah, maybe.
>
> Wouldn't it be the first place you'd look for it in?

If IO were a top-level category, yes, but no, I wouldn't look in
"standard library enhancements/IO" for serialization.

>>>>     Containers/data structures: 
>>>>       assign, pointer container, array, bitset, multi_index,
>>>>       multi-array, tuple
>>>
>>> Graph library, no?
>>
>> IMO, there's no huge advantage in using the BGL if all you're looking
>> for is a graph data structure.  Coding one up by hand will probably
>> give you something that's easier to work with.  The strong reason to
>> use the BGL is the algorithms.
>
> I'd say that's up to the user to decide, 

Absolutely.  I don't object to cross-listing it here, but I am averse
to "maximal cross-listing,"  at least for people trying to get a sense
of what's in Boost.

>>>> * System-level libraries
>>>>
>>>>     Program options, date-time, filesystem, threads, serialization,
>>>>     signals, pool, Python
>>>
>>>
>>> I don't see the logic behind putting all these together (nor does the
>>> name speak for any of them). What's common between Threads and
>>> Date-time, 
>>
>> time :^)
>>
>>> or, for that matter, Signals and Python? 
>>
>> Often used to glue together large systems while keeping parts decoupled.
>>
>>> Or Filesystem and Pool?
>>
>> Management of system resources.
>
> Well, OK, I'm sure we can find _something_ common between any two
> libraries :). The question is, is this categorization helpful to
> people who are looking for, say, a date-time library? IMO, no. At
> least I would have never guessed to look for it under this category.

Yeah, maybe this goes to what Beth meant about "browsing
vs. searching."  My page is oriented toward browsing.  And, IMO, if we
don't do too much cross-listing there are still few enough libraries
that the searcher can do all his work fairly efficiently with a
browsing-oriented page.  Once the list grows a lot, that will no longer
be true.

>>> IMO "Concurrent Programming", "Memory" and "Inter-language support"
>>> were perfect names for their corresponding content (which you've all
>>> bundled here).
>>
>> The problem is that categories with only one library in them are no
>> help to the navigator. 
>
> FWIW, "Memory" currently has three entries: pool, smart_ptr, and
> utility/checked_delete. Perhaphs more importantly, a category can be
> helpful even if it only contains a single entry: it adds context to
> the library name. "Pool" might not necessarily have something to do
> with memory, but place it under a telling category and it's enough
> information to save the user from diving in just to find out that it's
> not what she thought it is. Same with the just accepted "Shmem".
>
> And then there is the factor of precedent: put Python on the list
> without categorizing it, and hardly anybody will give it a second
> thought beyond "Hmm, interesting". Put it as a single entry under
> "Inter-language support", and you've got people thinking about other
> language binding libraries they've used/developed/heard about and why
> they are not in Boost.

Good points.

>> We might as well just move these libraries up to the top level.  As
>> I said, I was least convinced by this category, but I'm still not
>> sure there's a better grouping.
>
> I would:
>
> 1) Put Program Options and Serialization under "Standard Library
>    Enhancements" / "Input/Output" and Program Options alone under
>    "Standard Library Enhancements" / "Operating System Services" (see
>    below).

Huh, program options a standard library enhancement?  Serialization an
OS service?  I guess, if you see it that way, it must fit for some
fraction of people, but I don't get it.

> 2) Put Signals under "Functional Programming" (they _really_ should be
>    present in the same category as Function).

Really?  This is another one of those "it fits technically, but
doesn't speak to the purpose of the lib" things for me.

> 3) Put Pool under "Standard Library Enhancements" / "Memory
>    Management".

Okay.

> 4) Put Threads under "Standard Library Enhancements" / "Concurrent
>    Programming" and "Standard Library Enhancements" / "Operating
>    System Services".

Okay.

> 5) Put Date-time and Filesystem under "Standard Library Enhancements"
>    / "Operating System Services" (admittedly borrowed from Python docs
>    here: http://docs.python.org/lib/lib.html)

Yep, good.

> 6) Put Python under "Inter-language support".
>
> 7) Get rid of the "System-level libraries" category.

Sounds like a good direction, though some of the individual choices
don't make any sense to me.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com