[boost] Re: About iostate.zip 5

From: Daryle Walker (darylew_at_[hidden])
Date: 2002-04-10 21:03:26

on 3/25/02 3:00 PM, Edward D Brey at EdwardDBrey_at_[hidden] wrote:

>> From: Daryle Walker [mailto:darylew_at_[hidden]]
> 
> Thanks for the comments on the review comments.
> 
>> For example, we'll start a talk-show sub-library. To stop the sprawl of
>> headers in the top boost header directory, components for talk-shows will go
>> in a "talk_show" namespace (within the "boost" namespace).  To make the new
>> headers easy to find, the headers for stuff in the "talk_show" namespace will
>> go into the new "BOOST_ROOT/boost/talk_show" directory.
> 
> I like that you are applying a methodical approach here.  Before jumping into
> it though, it would probably be useful to identify the advantages of stopping
> the "sprawl".

A directory with lots of entries is harder to search through.  Also we have
a lot of names in the "boost" namespace.  There have been suggestions to use
sub-namespaces to prevent name collisions.  These sub-namespaces can be used
to separate the libraries to their various domains.  The directory
structures should match the name hierarchy to prevent confusion on how to
find an item.

> I find your use of the term sub-library curious.  Wouldn't we want to limit
> the collection of top-level directories to one per library, or else face a
> sprawl of TLDs?
[SNIP]

By a sub-library I mean what others here refer as a "(source) library," but
within a namespace-mirroring hierarchy.

>>> - Contents of index.html should be merged into iostate.html, since this is
>>> such a small library.  Having the extra level in between the main boost
>>> library page and the actual documentation of the library slows down
>>> browsing.  When the user clicks on iostate from the boost library index
>>> page, the first think that he should see is a brief description and a
>>> "Hello, world" example.
>> 
>> No.  See my future namespace, forwarding header, and sub-library philosophy
>> post.
> 
> What is your vision for the io library?  E.g. should lexical_cast be part of
> it?  What other features do you see being added?  I can see creating an io
> namespace if we have a general road-map on how to fill it.  Otherwise, I would
> be in favor of keeping ios_state a top-level utility.
[TRUNCATE]

The initial idea for the I/O library was introducing the stuff I wrote in
the more_io package in a piecemeal fashion.  Others are free to use it.  The
lexical_cast functionality could be moved if the maintainer wishes.  The
format package is an example of a new library that someone else did that
could also go there.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com