Subject: Re: [boost] Library dependencies and intrer-library code reuse
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2010-03-26 09:30:49
On Fri, Mar 26, 2010 at 3:11 AM, David Abrahams <dave_at_[hidden]> 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_at_[hidden]
> >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