David Abrahams wrote:
At Fri, 8 Oct 2010 10:46:33 -0800, Robert Ramey wrote:
Boost is getting bigger and bigger. This is a good thing.
The Boost header directory and boost namespace is also getting bigger and bigger. This is starting to become a problem.
Specifically, how? I don't like it either, but I'd like to know what the real-world effects are.
a) >> As boost get's bigger and bigger, it gets harder and harder to
install just a part of it. But installing just a part of it is what users need to become confident about it.
b) suppose I start with my "small" embedded system. Now I need shared_ptr and so I install boost. Now when something unexpected happens, I've now got to consider that that something is among thousands of lines of code that I for all practical purpposes I can't inspect. The giant size of boost means that I can accidently inject dependencies without being aware of them. Even if it never happens, I now have to consider this possibility everytime I have a problem. c) It's a real obstacle to convincing programmers to install and experiment with boost. These are already problems right now. They'll only get worse.
c) a couple of "catch all" namespaces/headers would be required such as "utility" for small libraries. I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library. If its a useful function which is shared by several libraries, it should be in something like: "unreviewed".
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? 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?
And of course these should have thier test and documenations in the corresponding "lib" subdirectory.
Which we don't currently have this for "detail" components.
I realize that we've been circling around this topic for a while, I just want to keep it alive.
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. Robert Ramey