[boost] [modularization] Recommendations

Subject: [boost] [modularization] Recommendations
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-06-08 06:21:44

Hello,

My last set of recommendations is here:

 http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245806

The current graph of strongly connected modules is:

 http://www.steveire.com/boost/2014_june8_all.dot
 http://www.steveire.com/boost/2014_june8_all.png

The 

 type_traits 
 mpl 
 typeof 
 core

form a closed cylce. I consider this a small problem and I recommend 
deferring efforts to resolve it for now and focusing on the other edges 
which impact the rest of the graph. It may not be realistic to resolve every 
cycle or doing so may involve merging modules etc. I recommend deferring 
that discussion/work until after the major cycle-forming-edges are resolved.

Group the above in the graph as a single node for now, removing many cycles: 

 http://www.steveire.com/boost/2014_june8_with_kernel.png
 http://www.steveire.com/boost/2014_june8_with_kernel.dot

Recommendation 1) Move parenthesized_type.hpp from parameter to core

This removes the dependency from concept_check on parameter.

Recommendation 2) Move implicit_cast.hpp and cast.hpp from conversion to 
core

This also requires moving select_type.hpp from detail to core.

This allows removal of the dependencies from iterator and range to 
conversion. As a side effect, it leaves lexical_cast as the only remaining 
public header in the conversion library. You can decide what impact that has 
for the recent 'Extracting lexical_cast from conversion' discussion.

This requires removing the include of numeric/conversion/cast.hpp from 
cast.hpp. The content of that was moved to the numeric library in 2005 and 
the include was left behind for source compatibility.

The result of the above recommendations is:

 http://www.steveire.com/boost/2014_june8_conversion_rdep.png
 http://www.steveire.com/boost/2014_june8_conversion_rdep.dot

Recommendation 3) Remove use of algorithm from range

Range includes 

 boost/algorithm/string/config.hpp

for no known purpose. According to 

 git log -S BOOST_STRING_TYPENAME

that define was never used in the range library. According to the history of 

 boost/algorithm/string/config.hpp

it never really had anything else useful. It might have made sense to 
include it for the Borland portability with the BOOST_STRING_TYPENAME, but 
that define was never used in range.

Simply remove the use of the

 boost/algorithm/string/config.hpp

header.

Use

 boost/type_traits/detail/yes_no_type.hpp

instead of 

 boost/algorithm/string/yes_no_type.hpp

in 

 include/boost/range/detail/collection_traits_detail.hpp

The resulting strongly connected graph is 

 http://www.steveire.com/boost/2014_june8_range_deps.png
 http://www.steveire.com/boost/2014_june8_range_deps.dot

There are more recommendations which can be made to reduce the strongly 
connected graph further, but I think the above are enough for now, so let's 
see if we can get through those first.

Thanks,

Steve.