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