Subject: Re: [boost] [modularization] Improving/splitting up detail
From: Daniel Pfeifer (daniel_at_[hidden])
Date: 2013-11-02 03:23:05
2013/11/2 Ahmed Charles <acharles_at_[hidden]>:
>> Date: Fri, 1 Nov 2013 22:34:07 +0000
>> From: daniel_at_[hidden]
>> To: boost_at_[hidden]
>> Subject: Re: [boost] [modularization] Improving/splitting up detail
>> On 1 November 2013 22:10, Daniel Pfeifer <daniel_at_[hidden]> wrote:
>> >> boost/detail/xxx.hpp
>> >> Used by YYY and ZZZ, move to "common"
>> > Isn't there already a dependency from YYY to ZZZ? Could we put xxx.hpp
>> > to ZZZ instead? Maybe a "common" is not even needed.
>> We should be careful about making changes just because they fit the
>> current dependencies. Dependencies are not constant, we don't want to
>> be in a situation where the dependency graph falls apart because of a
>> future change to one of these headers. Also, if a header is in detail
>> it should be potentially useful for future libraries which wouldn't
>> want to depend on ZZZ (if it isn't, then it shouldn't have been put in
>> detail in the first place).
> The goal is to create two 'modules' or libraries:
We had that originally. They were called "detail" and "core".
How do we describe those libraries to users? Those might be the
Frequently Questioned Answers:
A: It is a Boost library that you should not use.
Q: If it is not useful, why does it exist?
A: It is used internally by several Boost libraries.
Q: If it is so useful, why should I not use it too?
I prefer to have no such "detail" libraries at all. Everything that is
useful to a broader audience should be in utility.
Everything else should be an implementation detail of one library.
When one library depends on the implementation detail of another
library (ie. includes a 'detail' header from it), that is a smell, OK.
But at least it is hidden from users.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk