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 isn't silly. - Doug