Re: [boost] [type_traits] Modularization proposal

On Wed, Sep 17, 2014 at 6:28 AM, Andrey Semashev wrote:

On Wed, Sep 17, 2014 at 4:11 PM, Stephen Kelly 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.

+1

...

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.

Specifically, reducing the number of the libraries should always be secondary to the drive to reduce dependencies. If there is a part of an existing library that is logically complete and independently useful, it should be refactored into a separate component.

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.

+1

...

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.

...so that user code that needs a tiny piece of core doesn't pull in the kitchen sink.

...

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"?

+1 -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode