Re: [boost] [type_traits] Modularization proposal

Subject: Re: [boost] [type_traits] Modularization proposal
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-09-17 09:28:17

On Wed, Sep 17, 2014 at 4:11 PM, Stephen Kelly <hello_at_[hidden]> wrote:
> Andrey Semashev wrote:
>
>> I propose to extract common_type.hpp (and its implementation and tests)
>> into a sublib within type_traits (e.g. type_traits/common_type).
>
> Rather than creating tens of tiny 'sublibs' when considering one module at a
> time, all of the small libraries at the 'bottom' of the graph of boost
> libraries (ie the libraries with very few dependencies and which have many
> dependencies themselves) should be considered together for re-organization.

That's subject for a debate.

> You seem to be focusing on small problems which remove a small number of
> nodes from some dependency graphs in a few cases. There are bigger problems
> which, when fixed, drop tens of nodes in most cases. Those problems are the
> serialization->spirit edge and the range->algorithm edge. I would prioritize
> all this stuff at the 'bottom' of the graph after those big problems in
> order to get more benefit.

One of the goals of modularization is to eliminate circular
dependencies. Another is to reduce the amount of dependencies between
the libraries. I think, I'm working in both directions.

I prefer to work with low level libraries because there are lots of
other libs depending on them, and improving the situation on the low
level would result in more massive improvement overall. Compare the
number of libraries that depend on Serialization and TypeTraits, for
example. Also, I'm an active user of these libraries myself, so I'm
interested in their health.

I'm not trying to deminish the importance of the changes you propose,
it's just these libraries are not my primary concern right now.

> 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. Merging MPL.Core with Core would make Core heavier and
add more dependencies to it, which contradicts its incentive.

There is also maintainability issue - MPL.Core and MPL are tightly
coupled and share history. There is common documentation. And then
there is access permissions issue.

> 2) Given the number of dependers of these modules, they are all certainly
> "core". However, probably only a subset of files within them are depended
> on. What are those important files and why shouldn't they be moved to core?

Extracting MPL.Core was an attempt to identify those "most wanted"
headers. Merging MPL.Core and Core, I think, is a bad idea for the
reasons I mentioned above.

> 3) Is detail really a library at all? What is it? What is it for?

It's a collection of tools useful for multiple Boost libraries but not
good enough to be public. You can call it our private attic.

> 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.

> 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.
The solution is to make multiple such fundamental libs, each
implementing its part of common functionality and having minimal
dependencies.

> 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. What if my library only
needs BOOST_ASSERT? Do I have to pull half of MPL and TypeTraits along
in this "bigger core"?

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).