On Fri, Mar 26, 2010 at 3:11 AM, David Abrahams <dave@boostpro.com> wrote:
At Thu, 25 Mar 2010 22:58:45 -0500, Zachary Turner wrote:
On Thu, Mar 25, 2010 at 10:43 PM, Steven Watanabe <watanabesj@gmail.com wrote:
AMDG
Zachary Turner wrote:
So there we go. Does this work, and if not why not? Even if we
agree
it's a huge undertaking, is it worth it? And if not, why not?
Even if it were a good idea, it isn't going to happen. Nothing that requires that much effort is ever going to happen around here. If we did have that kind of manpower, I think there are many higher priorities.
Surely we can't adopt that stance forever can we? It's not difficult to imagine a scenario down the line where Boost has hundreds of independent libraries. This won't scale. It *cant* scale. But at the same time, it really doesn't make sense for everyone to continue reinventing wheels in every single new library that gets added to boost. It defeats the whole purpose of having a generic library in the first place, and makes the exact problem that everyone complains about (slow compile times) even worse!
Untangling (and minimizing) intra-library dependencies is certainly doable—the untangling part has already been done (http://gitorious.org/boost)—but you proposed something more radical… and probably impossible when you consider the pimpl/header-only requirement. A pimpl-based type traits library?
Ok, sure. In some cases it's not possible. I guess I didn't explicitly say that because I thought it was kind of obvious but you're right, I should have clarified, or at least not emphasized *every* library. But the point was that if it's possible, it should be done. I think that it's possible in large part for almost every library which is not strictly a metaprogramming library, or which generates some runtime code. Most libraries use some element of metaprogramming, but oftentimes they are internal details and the metaprogramming-related headers can be included only from CPP files. Like you said, minimizing inter-library dependencies isn't that impractical. My point was that I don't think minimizing inter-library dependencies is necessarily a worthy goal. We should *encourage* libraries to use other libraries, while mitigating the negative effects of these dependencies from the user's point of view. Zach