From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2007-06-20 18:30:24
On Wed, 2007-06-20 at 15:12 -0700, Robert Ramey wrote:
> A... so either something like BOOST_STATIC_ASSERT should have
> its own navigator even though its one page or Boost Serialization shouldn't
> have one even though its maybe 100 pages long? How can that make
> any sense?
I'd rather see little utilities like BOOST_STATIC_ASSERT folded into the
"utility" library. As we get more an more large libraries like
Serialization, it seems almost silly to have small things like
BOOST_STATIC_ASSERT be their own "library".
> I think the idea that boost can so consistent/coherent/uniform (or whatever
> term one wants to use) accross all its libraries (spanning 8 years so far)
> is unrealistic, and in general not a good idea. Variation in depth, scope,
> size, application area, etc is just too broad to think this is really
> doable, and attempts to make them look more alike than they are
> involve a lot of effort which could be better spent elsewhere. That
> making things more consistent can be a good idea - but its not
> an end in itself and can be taken too far.
Given that we've never seen anything like consistency in the Boost
documentation, I guess I'd like to see it first before we say that this
principle (which is often a very good principle) is rejected.
Here's what I'm saying, concretely: convert everything to
Quickbook/Boostbook and see how things work. Make that
expanding/collapsing tree control work for *all* Quickbook/Boostbook
documentation. Then, if we like it, we can decide when it's silly (say,
based on the depth/size of the table of contents) and use it when it
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk