Re: [boost] [type_traits] Modularization proposal

Subject: Re: [boost] [type_traits] Modularization proposal
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2014-09-17 14:58:02

On Wed, Sep 17, 2014 at 6:28 AM, Andrey Semashev <andrey.semashev_at_[hidden]>
wrote:

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

+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