Re: [boost] Library dependencies and intrer-library code reuse

Subject: Re: [boost] Library dependencies and intrer-library code reuse
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2010-03-25 23:58:45

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!

We can propose alternative solutions, but ultimately I don't see any way
around something that really does require that much effort.  Is it easier to
start embracing that effort now, when boost has a manageable (albeit still
large) number of libraries, or do we wait a couple years and realize that it
really is too late at that point?

In order for Boost to live on, I think there necessarily must be a system
such that a) Only selected libraries are exposed to the user, and b)
libraries can freely reuse other libraries without any noticeable
implications to the user.  If the reuse problem is not solved, maintenance
grows exponentially more complicated as time passes, as bugs in library A's
implementation of foo are not propagated to library B, C, D, and E's
implementation of foo.  This compounds as more libraries are added.  What
could have been fixed by 1 person needs to be fixed by 5 different people.
 If the selective external visibility problem is not solved, boost's sandbox
approach to adding more and more libraries will alienate more and more
people to the point that people really do just stop using it altogether.   I
see both of these outcomes as disastrous and I can't think of anything that
should be higher priority than making sure it doesn't happen.

I'm certainly open to alternatives, and I see some of them being discussed
independently in other threads on the list in recent days, but I think any
reasonable solution must be designed around both problems at the same time.