Re: [boost] [RFC] Header/namespace policy draft

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-12-02 21:03:32

Joel de Guzman wrote:
> David Abrahams wrote:

>> These components are tested and commented, but they are pretty
>> obscure, and making them into public Boost components would entail
>> writing rationales, tutorials, and formal interface documentation.  I
>> didn't have time for that, and almost nobody would have benefited from
>> it: adding more oddball components into the list at
>> http://boost.org/libs will only make it harder to find the useful
>> stuff.  
> 
> 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? You may
> say common sense will prevent people from doing so, but with a
> free for all addition into boost::detail, this is not a paranoid
> scenario in the future when Boost grows even bigger and a lot
> more things can go wrong, slipping from the common sense radar
> screen. Now, multiply that to hundreds of developers. To me, it
> will not be a pretty situation.
> 
> I do not see Boost.Iterator having dependence on Boost.Python if
> the common components are segregated sufficiently in, say,
> boost/python/support. Fusion was once hosted by Spirit and
> xpressive used Fusion. That does not mean that xpressive had a
> dependency on spirit. It's just the location.
> 
> Anyway, if it's used by both Boost.Python and Boost.Iterator,
> I'd say that Boost.Iterator should be the host since it is a
> core library.

To be clear, I meant to say that it's ok to have a common
utility for Boost.Python and Boost.Iterator to be in boost::detail
since Boost.Iterator is a core library.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net