Re: [boost] Road to low-quality-code is paved with good intentionsof dropping dependencies

Subject: Re: [boost] Road to low-quality-code is paved with good intentionsof dropping dependencies
From: Mikael Persson (mikael.s.persson_at_[hidden])
Date: 2015-01-07 14:02:24

Getting back to the issue at hand (creating a "base" library), I would like
to give my humble perspective on it.

I think that the root of the problem is that a lot of the fundamental
libraries in Boost, like type-traits, mpl, pp, utility, etc..., all have in
common the fact that they have a few extremely useful components that are
used widely both in the user-base at large and by other boost libraries (or
could be used by them), and often those components were the original
motivators for the creation of the library, but they also all have a number
of additional "fancy" features that make sense within their prime
application domains (and you can't blame library devs for wanting to
fancy-up their libraries) but also constitute significant additional bloat
for all those people who only need the few useful components. For instance,
most people probably use the MPL for its basic meta-functions, especially
the boolean stuff (if_, not_, and_...) for Sfinae and type selectors, but
very few people need or want to use the whole "compile-time STL" part of
MPL. The type-traits library is the same. And I think that if it were
possible to distil things down to some basic components, much of the
cross-dependencies and code-bloat would be eliminated, and other boost
libraries could rely on those components without too much concern about
getting bloated by them.

I seems to me that the Boost.Core library is intended to regroup those
things. But the real problem with getting a good set of components to put
in Boost.Core is that there is no clear picture of what people want and
what people don't want. The dependency analyser cannot capture things that
people (from other boost libraries) would want to use but decided not to
use (by implementing their own reduced version of it) for fear of too much
bloat and dependencies, and nor is it really fine-grained enough for this
purpose anyways. I think there might be a need for some form of
voting/review system for people to be able to declare what specific
components they would like to see added to Boost.Core (that would help them
avoid the dilemma of dep./bloat versus code duplication) versus what
specific components / features would need to be factored out of the
code (or left out of boost.core) because of it being overly bloated. This
would clearly have to be more fine-grained than just on a header-by-header
basis. And the boost mailing list is far from providing an adequate forum
for this type of thing. Or maybe people simply need to be more proactive in
raising issues on Boost.Core's github, as I know people seem to still be
just warming up to that mode of discussion.

Of course, from a practical standpoint, this is difficult to realize, but I
just felt I should throw that idea out there.

P.S.: I find that this discussion also exemplifies what I see as a big
problem with Boost discussions, that is, any decision-making discussion on
broader issues quickly digresses into people raising their favourite
pet-peeves (like compiler support reqs, git submoduling, distribution
issues, etc.) and discussing small examples at length (like
integral-constant).

Cheers,
Mikael.