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

Subject: Re: [boost] [modularization] Improving/splitting up detail
From: Ahmed Charles (acharles_at_[hidden])
Date: 2013-11-04 03:59:04

Then call them modules, tell users that libraries are made of modules and that's it. The fact that most libraries have a module called core or detail that is shared with most other libraries is utterly irrelevant to users. The fact that this allows them to use libraries while downloading and installing less other libraries is useful.
________________________________
From: Daniel Pfeifer
Sent: 11/2/2013 12:23 AM
To: Boost Developers List
Subject: Re: [boost] [modularization] Improving/splitting up detail

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost