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