Re: policy and rationale for directory and namespace organization?

From: mda_at_[hidden]
Date: 2001-09-26 00:04:15

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 06:20 PM 9/24/2001, mda_at_d... wrote:
>  >- boost/rational.hpp is self-contained; within it there is a
>  >namespace detail block (don't know why it isn't an anonymous
>  >namespace).
> 
> It's good programming practice for header files never to put names 
in the 
> anonymous namespace, to prevent pollution of that namespace.

is there just a single anonymous namespace? what happens with:
   namespace boost {namespace foobar {
   ...
   namespace {
   }
   ...
   }}
is that innermost namespace the same as a "top-level" anonymous
one? if so, then i guess i agree with you, though if that is how
C++ works, it seems like it kind of disables part of the point
of anonymous namespaces.

does anyone besides boost use "detail"? where did that come from?
why not "impl" or "priv"?
are the semantics of "detail" to mean "don't go here" or is it
more like "advanced users only"?

> The source files need to be in a different directory hierarchy; 
that's 
> already been hashed out many times in the past.

hmmm, ok. i think boost makes good points about the importance
of stating rationales; it'd be nice if these determinations were
stated on the web site with rational (or a url to a past
mailing list thread, if easier).

> So what happens if you apply those guidelines to the current 
> libraries?  That's the proof of the pudding.

there are many violations, some of which i listed.
that inconsistency is in fact what started me off in the first place.
current behavior is so inconsistent that it would
be difficult to state any meaningful guidelines that wouldn't conflict
with current libraries.

> I'm not necessarily suggest we go back and change existing 
libraries, but 
> that we do make sure any new guidelines would have sense if they 
had been 
> originally applied when the libraries were initially developed.

i wouldn't necessarily suggest retroactive cleanup on this either.
i also don't think the mandatory list of guidelines concerning
namespaces and subdirectories should be long.
there might be a longer list of optional conventions.

also, i'm not just kvetching, i'm honestly curious what others
would suggest generally on this topic even if not applied to boost.
classes add another factor. for example, boost/pool/ is entirely
in a subdirectory, with no top-level header file, even though
it is in namespace boost -- because there is a "pool" class.
is that "ok"? maybe.

i'm not prepared to posit a set of guidelines
i could defend; i'm just sure an improvement could be made over
current behavior. so maybe i should shut up :).

> What's the problem with "files by the same name in different 
> directories"?  Some names like "Jamfile" are requirements of tools, 
others 
> are just plain convenient.  As more and more libraries are added, 
keeping 
> names totally unique is impractical.

i agree with things like "Makefile". but when for example you
have both boost/call_traits.hpp and boost/detail/call_traits.hpp,
it can get confusing in my editor or debugger.
it is a niggling issue.

-mda