At Fri, 8 Oct 2010 13:20:25 -0800, Robert Ramey wrote:
But in general it's not unreviewed code. It was usually part of a library that passed review, and then the code was factored out. So it doesn't have the same standing as a Boost library, and it may not have any user-level documentation, because... it's an implementation detail of various Boost libraries.
Hmmmm - if its reviewed and placed in a "global" namespace like boost::detail why not just include it in boost::utility then?
sure, if you'll agree to document and maintain it at a level suitable for users, be my guest :-) Also, theoretically, putting new components in boost::utility requires some kind of additional review process. I think we need a separate designation for the sorts of things that end up in boost::detail.
if its used for just one library, then why not make it a part of that one library rather than putting it in a global namespace?
That's exactly what one does. The only reason most of us ever put something in boost::detail is that it's needed by multiple libraries.
Don't worry, Ryppl isn't dead either; it's just been quiet for a while ;-)
I see this evolution as something necessary on it's own. Rypple may or maynot occur, but I think boost should evolve in this direction regardless. For now, I'm proposing these changes only for new libraries.
Well, we could do Boost modularization separately from ryppl. Eric's been maintaining a modularized mirror of boost at http://github.com/boost-lib -- Dave Abrahams BoostPro Computing http://www.boostpro.com