[type_traits] Modularization proposal
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.
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 -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-Modularization-proposal-tp466... Sent from the Boost - Dev mailing list archive at Nabble.com.
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.
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.
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.
On September 16, 2014 3:47:32 PM EDT, Andrey Semashev <andrey.semashev@gmail.com> 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)
On Wed, Sep 17, 2014 at 5:27 AM, Rob Stewart <robertstewart@comcast.net> wrote:
On September 16, 2014 3:47:32 PM EDT, Andrey Semashev <andrey.semashev@gmail.com> 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.
On September 17, 2014 12:26:16 AM EDT, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On September 16, 2014 3:47:32 PM EDT, Andrey Semashev <andrey.semashev@gmail.com> 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
On Wed, Sep 17, 2014 at 5:27 AM, Rob Stewart <robertstewart@comcast.net> wrote: 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)
On Wed, Sep 17, 2014 at 1:12 PM, Rob Stewart <robertstewart@comcast.net> 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.
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.
+1
The problem is that dependencies (for installation, not compilation) will unlikely be tracked on per-header basis, but rather on per-library basis.
The point is that currently there is no tracking of dependencies at all, as I've said before it's all vapour-ware at present, I see no great benefit in pushing stuff around until there's a definite target to aim at. John.
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?
On Wed, Sep 17, 2014 at 1:18 PM, Peter Dimov <lists@pdimov.com> 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.
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.
On Wed, Sep 17, 2014 at 1:45 PM, Peter Dimov <lists@pdimov.com> 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.
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>
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?
Because it breaks users code? John.
Le 16/09/14 21:47, Andrey Semashev a écrit :
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
On Tuesday 16 September 2014 20:06:27 John Maddock wrote: 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
On Wed, Sep 17, 2014 at 3:21 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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.
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.
On Wed, Sep 17, 2014 at 4:11 PM, Stephen Kelly <hello@steveire.com> 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).
On Wed, Sep 17, 2014 at 5:28 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Wed, Sep 17, 2014 at 4:11 PM, Stephen Kelly <hello@steveire.com> 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.
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.
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.
On Wed, Sep 17, 2014 at 6:28 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Wed, Sep 17, 2014 at 4:11 PM, Stephen Kelly <hello@steveire.com> 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
participants (8)
-
Andrey Semashev -
Emil Dotchevski -
John Maddock -
Peter Dimov -
Rob Stewart -
Robert Ramey -
Stephen Kelly -
Vicente J. Botet Escriba