Re: [boost] [modularization] Improving/splitting up detail

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.

-- Daniel