Boost logo

Boost :

Subject: Re: [boost] [type_traits] Modularization proposal
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-09-17 10:08:04


Andrey Semashev wrote:

>> 1) Why does mplcore exist? Why is its content not in core?
>
> Because it has a distinct set of functionality which may not be needed
> by a Core user.

Pick any two things in core. One of them might be needed by some user of it
while the other is not.

> Merging MPL.Core with Core would make Core heavier and
> add more dependencies to it, which contradicts its incentive.

... or it could consume those dependencies (or at least be in the same repo
and the same modularized release tarball) and really be core.

>> 4) Why is static_assert not part of core? What is the value of it being
>> seprate?
>
> Frankly, I would merge it with Assert or Config, although I did not
> analyze reports to see the consequences. In any case, it's a leaf
> library, so it doesn't add much.

What do you think the term 'leaf' means?

What the separation 'adds' is extra/different/separate things you need to
have/get before you can use a higher-level library.

>
>> 5) What if core actually contained 'core stuff'? What if core contained
>> 'toolchain normalization' (such as static_assert emulation, a
>> BOOST_STATIC_CONSTANT macro, etc) and facilities essential (ie, core) to
>> the rest of boost?
>
> The problem is that the set of "essential facilities" differ from one
> Boost library to another. Some only needs Config, other need stuff
> from Core and Preprocessor, third require MPL, TypeTraits and Utility.

True...

> The solution is to make multiple such fundamental libs, each
> implementing its part of common functionality and having minimal
> dependencies.

Leading to the apparent 'ideal' of one class per library.

An alternative solution would be to group the (small amount of) fundamental
stuff together in one repo/library. That's at least what QtCore does, for
example. It doesn't matter if two classes within it are technically
unrelated. The suggestion is providing a one-stop-shop (download tarball or
repo) for the core stuff which between 60 and 88 of the libraries in boost
use, because it is 'core'.

Then the challenge is balance between keeping it small enough and keeping it
relevant enough (by actually having core stuff in it).

>> 6) What if core was bigger? What if using boost library Foo only required
>> me to download/install boost core and a *small* handful of other
>> *independent* (not interdependent, as most of boost is now) dependencies
>> in order to use it? This trend of creating tens of tiny 1/2/3 file
>> "libraries" and "sublibs" runs/sprints against that kind of scenario.
>
> This would be a step towards monolithic Boost.

No, not really. It would be analysis of what the core stuff is, and then
grouping that core stuff together. A dependency on Boost.Core should not be
a problem and should provide core stuff. Boost.Core should be designed so
that that is true.

[Aside: current boost is not much less monolithic than it was in svn. It's
released/downloadable monolithically]

> What if my library only
> needs BOOST_ASSERT? Do I have to pull half of MPL and TypeTraits along
> in this "bigger core"?

Yes. You as a developer would install boost-core.git or boost-core.tar.gz
and then you would develop mylib, whatever it is.

A user could download/install boost-core.tar.gz and mylib.tar.gz instead of
boost-mplcore.tar.gz, boost-static_assert.tar.gz and boost-assert.tar.gz
before getting to mylib.tar.gz.

Very little depends on only one of these 'low level' libraries.

> As I see it, the problem with the current state is not the amount of
> core libraries but the unnecessary transitive dependencies they
> impose. It's not a problem to download Core and MPL.Core separately,
> as long as these libs don't require much themselves (like Utility or
> TypeTraits, for example).

Similarly, if they don't require much themselves (and if most dependers use
both of them), it's not a problem to combine them.

Thanks,

Steve.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk