on Mon Dec 03 2007, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
David Abrahams wrote:
My concern is that this policy does not seem to be scalable. What's to prevent someone from adding hundreds of small things (typedefs, enums, small classes, etc.) in boost detail?
The policy does. It says you only do that when they are in fact needed by multiple libraries. And anyway, what's wrong with having hundreds of small things in boost detail?
--The same reasons why we use sub-namespaces and sub-directories. Multiply that with the number of Boost developers past and present. The single boost::detail namespace can become utterly crowded.
OK, you have good points. I won't argue this any more. My only concern is a crowded boost::detail namespace in the future. Perhaps what we can do is subdivide boost::detail in the future when the need arises.
That sounds entirely sensible. Unlike public interfaces, we can refactor boost/detail as much as we want without breaking any code because we have access to all the code that depends on boost/detail. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com