[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [type_traits] Modularization proposal
From:       Stephen Kelly <hello () steveire ! com>
Date:       2014-09-17 12:11:31
Message-ID: lvbtpb$5uv$1 () ger ! gmane ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]