[type_traits] Modularization proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[type_traits] Modularization proposal

Andrey Semashev-2
Hi,

Boost.TypeTraits is used in lots of other Boost libraries, and it currently
unnecessarily pulls MPL and TypeOf. The dependencies are introduced by just
these two public headers: floating_point_promotion.hpp and common_type.hpp.
I'd like to avoid these dependencies.

I propose to extract common_type.hpp (and its implementation and tests) into a
sublib within type_traits (e.g. type_traits/common_type).

As for floating_point_promotion.hpp, it is used in promote.hpp, which is using
integral_promotion.hpp. I can see two ways of tackling it:

1. Extract all promotion traits into a sublib (e.g. type_traits/promotion).
This includes floating_point_promotion.hpp, integral_promotion.hpp and
promote.hpp, as well as their tests.

2. Change floating_point_promotion.hpp to not use MPL. MPL is used only to
workaround BOOST_NO_CV_SPECIALIZATIONS, which is defined for Borland 5.51 and
older and MPW 8.90 and older. The simplest way is to drop the workaround, but
at a quick glance it should be possible to retain it.

I'm currently leaning towards the option 2, although we obviously don't test
those compilers and there is no way of knowing if the code will still work
after the change. So I'm interested to know others' opinion, both with regard
to the general idea and the way of proceeding with
floating_point_promotion.hpp in particular.


PS: TypeTraits dependencies can be seen in the report Peter graciously
uploaded:

http://www.pdimov.com/tmp/report-d5ca5be/type_traits.html

After the modularization efforts TypeTraits should only depend on Config,
Core, Preprocessor, MPL.Core and StaticAssert. Don't mind that MPL.Core
depends on MPL - the pull request fixing it has already been created.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Robert Ramey
Andrey Semashev-2 wrote
Hi,

I propose to extract common_type.hpp (and its implementation and tests) into a
sublib within type_traits (e.g. type_traits/common_type).
I would like to know what "sub lib" means in this context.  Is it a git submodule?
Something that is somehow "embedded" in another module or what?

I all you mean is that it has it's own module in our current "flat" list of modules
that might be OK.  Though it's unclear about what benefit it has.

See my other post on this subject.

The "modularization" can't be considered independently of the benefit is
it mean to provide.  Possible benefits might be

a) faster builds
b) easier maintenance
c) smaller distributions of boost subsets
d) more clearly defined responsibilities

and of course there might be other consequences depending on how modularization is "undertaken"

a) slower builds
b) harder maintenance
c) larger distributions of boost subsets
e) less clearly defined responsibilities amongst boost authors.

But what i really missing is which benefits we hope to achieve for which group of users.  I haven't seen this yet.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
On Tuesday 16 September 2014 11:04:14 Robert Ramey wrote:

> Andrey Semashev-2 wrote
>
> > Hi,
> >
> > I propose to extract common_type.hpp (and its implementation and tests)
> > into a
> > sublib within type_traits (e.g. type_traits/common_type).
>
> I would like to know what "sub lib" means in this context.  Is it a git
> submodule?
> Something that is somehow "embedded" in another module or what?

It's not a git submodule. Technically, it's a top level directory in the same
git repository, which has nested include, test, etc. subdirectories which
constitute the sublibrary. See mpl and mpl/core for example.

> But what i really missing is which benefits we hope to achieve for which
> group of users.  I haven't seen this yet.

I replied in the other thread.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

John Maddock-3
In reply to this post by Andrey Semashev-2
> Boost.TypeTraits is used in lots of other Boost libraries, and it currently
> unnecessarily pulls MPL and TypeOf. The dependencies are introduced by just
> these two public headers: floating_point_promotion.hpp and common_type.hpp.
> I'd like to avoid these dependencies.
>
> I propose to extract common_type.hpp (and its implementation and tests) into a
> sublib within type_traits (e.g. type_traits/common_type).
>
> As for floating_point_promotion.hpp, it is used in promote.hpp, which is using
> integral_promotion.hpp. I can see two ways of tackling it:
>
> 1. Extract all promotion traits into a sublib (e.g. type_traits/promotion).
> This includes floating_point_promotion.hpp, integral_promotion.hpp and
> promote.hpp, as well as their tests.

What happens to boost/type_traits.hpp in this scheme (which depends on
*all* of type_traits)?

> 2. Change floating_point_promotion.hpp to not use MPL. MPL is used only to
> workaround BOOST_NO_CV_SPECIALIZATIONS, which is defined for Borland 5.51 and
> older and MPW 8.90 and older. The simplest way is to drop the workaround, but
> at a quick glance it should be possible to retain it.
>
> I'm currently leaning towards the option 2, although we obviously don't test
> those compilers and there is no way of knowing if the code will still work
> after the change. So I'm interested to know others' opinion, both with regard
> to the general idea and the way of proceeding with
> floating_point_promotion.hpp in particular.

+1 on option 2.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
On Tuesday 16 September 2014 20:06:27 John Maddock wrote:

> > Boost.TypeTraits is used in lots of other Boost libraries, and it
> > currently
> > unnecessarily pulls MPL and TypeOf. The dependencies are introduced by
> > just
> > these two public headers: floating_point_promotion.hpp and
> > common_type.hpp.
> > I'd like to avoid these dependencies.
> >
> > I propose to extract common_type.hpp (and its implementation and tests)
> > into a sublib within type_traits (e.g. type_traits/common_type).
> >
> > As for floating_point_promotion.hpp, it is used in promote.hpp, which is
> > using integral_promotion.hpp. I can see two ways of tackling it:
> >
> > 1. Extract all promotion traits into a sublib (e.g.
> > type_traits/promotion).
> > This includes floating_point_promotion.hpp, integral_promotion.hpp and
> > promote.hpp, as well as their tests.
>
> What happens to boost/type_traits.hpp in this scheme (which depends on
> *all* of type_traits)?

Hmm, I didn't notice that header. Ok, assuming we don't want to move this one
header to its own sublib, what if we approach it from the other side. We can
move all type traits except common_type.hpp and type_traits.hpp to a sublib
base (i.e. type_traits/base). floating_point_promotion.hpp would be changed to
not depend on MPL before moving to base.

Side note: I don't want to reserve the name 'core' for there were discussions
about creating TypeTraits.Core that would not depend on MPL.Core.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Rob Stewart-6
On September 16, 2014 3:47:32 PM EDT, Andrey Semashev <[hidden email]> wrote:

>On Tuesday 16 September 2014 20:06:27 John Maddock wrote:
>> > Boost.TypeTraits is used in lots of other Boost libraries, and it
>> > currently
>> > unnecessarily pulls MPL and TypeOf. The dependencies are introduced
>> > by just
>> > these two public headers: floating_point_promotion.hpp and
>> > common_type.hpp.
>> > I'd like to avoid these dependencies.
>> >
>> > I propose to extract common_type.hpp (and its implementation and
>tests)
>> > into a sublib within type_traits (e.g. type_traits/common_type).
>> >
>> > As for floating_point_promotion.hpp, it is used in promote.hpp,
>which is
>> > using integral_promotion.hpp. I can see two ways of tackling it:
>> >
>> > 1. Extract all promotion traits into a sublib (e.g.
>> > type_traits/promotion).
>> > This includes floating_point_promotion.hpp, integral_promotion.hpp
>and
>> > promote.hpp, as well as their tests.
>>
>> What happens to boost/type_traits.hpp in this scheme (which depends
>on
>> *all* of type_traits)?
>
>Hmm, I didn't notice that header. Ok, assuming we don't want to move
>this one
>header to its own sublib, what if we approach it from the other side.
>We can
>move all type traits except common_type.hpp and type_traits.hpp to a
>sublib
>base (i.e. type_traits/base). floating_point_promotion.hpp would be
>changed to
>not depend on MPL before moving to base.

This seems almost ridiculous. If one can choose to not include the headers that incur the dependencies, then one can avoid then when desired. Those that don't care will just include boost/type_traits.hpp.

___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
On Wed, Sep 17, 2014 at 5:27 AM, Rob Stewart <[hidden email]> wrote:

> On September 16, 2014 3:47:32 PM EDT, Andrey Semashev <[hidden email]> wrote:
>>
>>Hmm, I didn't notice that header. Ok, assuming we don't want to move
>>this one
>>header to its own sublib, what if we approach it from the other side.
>>We can
>>move all type traits except common_type.hpp and type_traits.hpp to a
>>sublib
>>base (i.e. type_traits/base). floating_point_promotion.hpp would be
>>changed to
>>not depend on MPL before moving to base.
>
> This seems almost ridiculous. If one can choose to not include the headers that incur the dependencies, then one can avoid then when desired. Those that don't care will just include boost/type_traits.hpp.

The problem is that dependencies (for installation, not compilation)
will unlikely be tracked on per-header basis, but rather on
per-library basis.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Rob Stewart-6
On September 17, 2014 12:26:16 AM EDT, Andrey Semashev <[hidden email]> wrote:

>On Wed, Sep 17, 2014 at 5:27 AM, Rob Stewart
><[hidden email]> wrote:
>> On September 16, 2014 3:47:32 PM EDT, Andrey Semashev
><[hidden email]> wrote:
>>>
>>>Hmm, I didn't notice that header. Ok, assuming we don't want to move
>>>this one
>>>header to its own sublib, what if we approach it from the other side.
>>>We can
>>>move all type traits except common_type.hpp and type_traits.hpp to a
>>>sublib
>>>base (i.e. type_traits/base). floating_point_promotion.hpp would be
>>>changed to
>>>not depend on MPL before moving to base.
>>
>> This seems almost ridiculous. If one can choose to not include the
>headers that incur the dependencies, then one can avoid them when
>desired. Those that don't care will just include boost/type_traits.hpp.
>
>The problem is that dependencies (for installation, not compilation)
>will unlikely be tracked on per-header basis, but rather on
>per-library basis.

The effect of what you propose is to change include directives, right? I'd prefer to avoid that. Forcing users to recall that all Type Traits headers are in the type_traits directory except a tiny subset is a cure worse than the disease.

Surely we can capture installation dependencies another way.


___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Peter Dimov-2
In reply to this post by Andrey Semashev-2
Andrey Semashev wrote:
> On Tuesday 16 September 2014 20:06:27 John Maddock wrote:
> > What happens to boost/type_traits.hpp in this scheme (which depends on
> > *all* of type_traits)?
>
> Hmm, I didn't notice that header. Ok, assuming we don't want to move this
> one header to its own sublib, what if we approach it from the other side.
> We can move all type traits except common_type.hpp and type_traits.hpp to
> a sublib base (i.e. type_traits/base). floating_point_promotion.hpp would
> be changed to not depend on MPL before moving to base.

How about we just remove the common_type include from type_traits.hpp?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
On Wed, Sep 17, 2014 at 1:18 PM, Peter Dimov <[hidden email]> wrote:

> Andrey Semashev wrote:
>>
>> On Tuesday 16 September 2014 20:06:27 John Maddock wrote:
>> > What happens to boost/type_traits.hpp in this scheme (which depends on >
>> > *all* of type_traits)?
>>
>> Hmm, I didn't notice that header. Ok, assuming we don't want to move this
>> one header to its own sublib, what if we approach it from the other side. We
>> can move all type traits except common_type.hpp and type_traits.hpp to a
>> sublib base (i.e. type_traits/base). floating_point_promotion.hpp would be
>> changed to not depend on MPL before moving to base.
>
>
> How about we just remove the common_type include from type_traits.hpp?

That would be a breaking change, wouldn't it? And it doesn't scale if
we want to modularize further for some reason.

I think we should establish practice of dealing with "include all"
headers since it's not the only one example.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
In reply to this post by Rob Stewart-6
On Wed, Sep 17, 2014 at 1:12 PM, Rob Stewart <[hidden email]> wrote:
>
> The effect of what you propose is to change include directives, right? I'd prefer to avoid that.

No, neither include directives nor client's code will change. All
headers will be in boost/type_traits as they are now. They will just
link to different locations within libs/type_traits and
libs/type_traits/base.

Please, have a look at how it works with MPL and MPL.Core now.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Peter Dimov-2
In reply to this post by Andrey Semashev-2
Andrey Semashev wrote:
> > How about we just remove the common_type include from type_traits.hpp?
>
> That would be a breaking change, wouldn't it?

It will break code that includes boost/type_traits.hpp and uses
boost::common_type, yes. Since common_type is a relatively late addition,
such code is, I submit, rare.

It will also break the dependency of boost/type_traits.hpp on typeof. There
are many libraries that include type_traits.hpp and do not use common_type,
and this will automatically make them not depend on typeof.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
On Wed, Sep 17, 2014 at 1:45 PM, Peter Dimov <[hidden email]> wrote:

> Andrey Semashev wrote:
>>
>> > How about we just remove the common_type include from type_traits.hpp?
>>
>> That would be a breaking change, wouldn't it?
>
>
> It will break code that includes boost/type_traits.hpp and uses
> boost::common_type, yes. Since common_type is a relatively late addition,
> such code is, I submit, rare.
>
> It will also break the dependency of boost/type_traits.hpp on typeof. There
> are many libraries that include type_traits.hpp and do not use common_type,
> and this will automatically make them not depend on typeof.

I think such libraries should be fixed instead (by replacing
type_traits.hpp inclusion with more specific headers).

What is the reason of having type_traits.hpp in the first place? If
it's an "include all" header to simplify user's life then "all" means
all, including common_type, IMHO.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Peter Dimov-2
Andrey Semashev wrote:
> What is the reason of having type_traits.hpp in the first place? If it's
> an "include all" header to simplify user's life then "all" means all,
> including common_type, IMHO.

I consider common_type a separate mini-library, and as such, it seems
defensible to me for type_traits.hpp to not include it. Stated differently,
I don't consider it part of "all".

> I think such libraries should be fixed instead (by replacing
> type_traits.hpp inclusion with more specific headers).

If we consider use of type_traits.hpp a defect to be fixed, it doesn't make
much sense to have it.

Either way, here's the list.

Inclusion report for <boost/type_traits.hpp> (in module type_traits):

    from convert:
        <boost/convert/detail/is.hpp>

    from detail:
        <boost/detail/numeric_traits.hpp>

    from geometry:
        <boost/geometry/algorithms/assign.hpp>
        <boost/geometry/algorithms/detail/as_range.hpp>
        <boost/geometry/algorithms/detail/assign_values.hpp>
        <boost/geometry/algorithms/detail/recalculate.hpp>
        <boost/geometry/algorithms/length.hpp>
        <boost/geometry/core/cs.hpp>
        <boost/geometry/core/reverse_dispatch.hpp>
        <boost/geometry/core/tag_cast.hpp>
        <boost/geometry/extensions/gis/geographic/strategies/distance_cross_track.hpp>
        <boost/geometry/io/wkt/read.hpp>
        <boost/geometry/policies/robustness/get_rescale_policy.hpp>
        <boost/geometry/policies/robustness/rescale_policy.hpp>
        <boost/geometry/policies/robustness/robust_type.hpp>
        <boost/geometry/strategies/cartesian/centroid_bashein_detmer.hpp>
        <boost/geometry/strategies/cartesian/distance_projected_point.hpp>
        <boost/geometry/strategies/cartesian/distance_projected_point_ax.hpp>
        <boost/geometry/strategies/cartesian/distance_pythagoras.hpp>
        <boost/geometry/strategies/cartesian/side_by_triangle.hpp>
        <boost/geometry/strategies/spherical/distance_cross_track.hpp>
        <boost/geometry/strategies/spherical/side_by_cross_track.hpp>
        <boost/geometry/strategies/spherical/ssf.hpp>
        <boost/geometry/util/bare_type.hpp>
        <boost/geometry/util/calculation_type.hpp>
        <boost/geometry/util/combine_if.hpp>
        <boost/geometry/util/parameter_type_of.hpp>
        <boost/geometry/util/promote_floating_point.hpp>
        <boost/geometry/util/select_calculation_type.hpp>
        <boost/geometry/util/select_most_precise.hpp>

    from gil:
        <boost/gil/channel_algorithm.hpp>
        <boost/gil/color_base.hpp>
        <boost/gil/color_base_algorithm.hpp>
        <boost/gil/device_n.hpp>
        <boost/gil/gil_concept.hpp>
        <boost/gil/gray.hpp>
        <boost/gil/metafunctions.hpp>
    <boost/gil/pixel.hpp>
    <boost/gil/utilities.hpp>

from graph:
    <boost/graph/adjacency_matrix.hpp>
    <boost/graph/boyer_myrvold_planar_test.hpp>
    <boost/graph/dijkstra_shortest_paths.hpp>
    <boost/graph/directed_graph.hpp>
    <boost/graph/named_function_params.hpp>
    <boost/graph/properties.hpp>
    <boost/graph/reverse_graph.hpp>
    <boost/graph/subgraph.hpp>
    <boost/graph/two_graphs_common_spanning_trees.hpp>
    <boost/graph/undirected_graph.hpp>
    <boost/pending/property.hpp>

from icl:
    <boost/icl/functors.hpp>

from iterator:
    <boost/iterator/new_iterator_tests.hpp>
    <boost/pending/iterator_tests.hpp>

from msm:
    <boost/msm/back/state_machine.hpp>
    <boost/msm/front/euml/container.hpp>
    <boost/msm/front/euml/operator.hpp>
    <boost/msm/mpl_graph/detail/incidence_list_graph.ipp>

from multi_array:
    <boost/multi_array.hpp>

from numeric~odeint:
    <boost/numeric/odeint/algebra/detail/macros.hpp>
    <boost/numeric/odeint/stepper/bulirsch_stoer_dense_out.hpp>

from numeric~ublas:
    <boost/numeric/ublas/traits.hpp>
    <boost/numeric/ublas/vector_of_vector.hpp>

from property_map:
    <boost/property_map/compose_property_map.hpp>
    <boost/property_map/function_property_map.hpp>
    <boost/property_map/parallel/unsafe_serialize.hpp>
    <boost/property_map/transform_value_property_map.hpp>
from python:
    <boost/python/detail/defaults_def.hpp>

from signals:
    <boost/signals/trackable.hpp>

from tr1:
    <boost/tr1/type_traits.hpp>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Vicente Botet
In reply to this post by Andrey Semashev-2
Le 16/09/14 21:47, Andrey Semashev a écrit :

> On Tuesday 16 September 2014 20:06:27 John Maddock wrote:
>>> Boost.TypeTraits is used in lots of other Boost libraries, and it
>>> currently
>>> unnecessarily pulls MPL and TypeOf. The dependencies are introduced by
>>> just
>>> these two public headers: floating_point_promotion.hpp and
>>> common_type.hpp.
>>> I'd like to avoid these dependencies.
>>>
>>> I propose to extract common_type.hpp (and its implementation and tests)
>>> into a sublib within type_traits (e.g. type_traits/common_type).
>>>
>>> As for floating_point_promotion.hpp, it is used in promote.hpp, which is
>>> using integral_promotion.hpp. I can see two ways of tackling it:
>>>
>>> 1. Extract all promotion traits into a sublib (e.g.
>>> type_traits/promotion).
>>> This includes floating_point_promotion.hpp, integral_promotion.hpp and
>>> promote.hpp, as well as their tests.
>> What happens to boost/type_traits.hpp in this scheme (which depends on
>> *all* of type_traits)?
> Hmm, I didn't notice that header. Ok, assuming we don't want to move this one
> header to its own sublib, what if we approach it from the other side. We can
> move all type traits except common_type.hpp and type_traits.hpp to a sublib
> base (i.e. type_traits/base). floating_point_promotion.hpp would be changed to
> not depend on MPL before moving to base.
>
This will work. However, currently the submodules depend on the module,
not the opposite. I don't know if this is perturbing.
So, here is another alternative. Let everything in place except
type_traits.hpp type_traits/common_type.hpp, which are move to two
sub-modules TypeTraits.All and TypeTraits.CommonType with the following
dependencies

TypeTraits.All -> TypeTraits TypeTraits.CommonType
TypeTraits.CommonType -> TypeTraits TypeOf
TypeOf -> TypeTraits

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
On Wed, Sep 17, 2014 at 3:21 PM, Vicente J. Botet Escriba
<[hidden email]> wrote:

> Le 16/09/14 21:47, Andrey Semashev a écrit :
>
>> Hmm, I didn't notice that header. Ok, assuming we don't want to move this
>> one
>> header to its own sublib, what if we approach it from the other side. We
>> can
>> move all type traits except common_type.hpp and type_traits.hpp to a
>> sublib
>> base (i.e. type_traits/base). floating_point_promotion.hpp would be
>> changed to
>> not depend on MPL before moving to base.
>>
> This will work. However, currently the submodules depend on the module, not
> the opposite. I don't know if this is perturbing.

I don't think there is implied dependency of sublibs on the main
library (if there is one). At least, I did not get that impression
from Peter's reports and earlier discussions.

> So, here is another alternative. Let everything in place except
> type_traits.hpp type_traits/common_type.hpp, which are move to two
> sub-modules TypeTraits.All and TypeTraits.CommonType with the following
> dependencies
>
> TypeTraits.All -> TypeTraits TypeTraits.CommonType
> TypeTraits.CommonType -> TypeTraits TypeOf
> TypeOf -> TypeTraits

Yes, in this case we move a single type_traits.hpp to its own sublib.
It looks a little awkward to me but I'm ok with it if John agrees.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Stephen Kelly-2
In reply to this post by Andrey Semashev-2
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.

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.

However, you're obviously not going to path on your path just because I
suggest it, so I do have some thoughts on this bottom-of-the-build-graph
stuff.

Considering only one existing library at a time (mpl before, resulting in
the mplcore split-out) and now type_traits (resulting in, what, 4 proposed  
'sublibs'?) misses other opportunities to reorganize.

Under the criteria of 'has few dependencies and many dependers', some of the
libraries to consider together (and consider their content together) are:

* core
* mpl
* mplcore
* type_traits
* utility
* detail
* static_assert
* assert
* throw_exception
* utility
* config

[NB: because I know some on this mailing list are going to use their
imagination more than others while reading this mail:

I'm not saying 'just throw them all together'.
I'm saying 'do some analysis, do some thinking, do some looking'.
]

1) Why does mplcore exist? Why is its content not in core?

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?

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

4) Why is static_assert not part of core? What is the value of it being
seprate?

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?

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.


Thanks,

Steve.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
On Wed, Sep 17, 2014 at 4:11 PM, Stephen Kelly <[hidden email]> 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).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Andrey Semashev-2
On Wed, Sep 17, 2014 at 5:28 PM, Andrey Semashev
<[hidden email]> wrote:

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

Also this would make dependency management on the higher level easier.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Modularization proposal

Stephen Kelly-2
Andrey Semashev wrote:

>> 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.
>
> Also this would make dependency management on the higher level easier.

I don't agree with that. Most of the 'higher' libraries depend on
many/multiple of these 'lower' libraries anyway, and these changes to the
'lower' libraries don't have any effect on the problems at the higher
levels.

Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12