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

Subject: Re: [boost] [modularization] Improving/splitting up detail
From: Ahmed Charles (acharles_at_[hidden])
Date: 2013-11-02 02:18:38

> 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:

1. "detail" - which only depend on config
2. "common" which has minimal dependencies and contains code useful to multiple libraries (hopefully it doesn't depend on things that depend on it).

So, by definition, there can't be a change to detail which intentionally adds dependencies, since that is forbidden by the goals of the library. Of course, people can make mistakes, but they would then be fixed and the desired invariant would hold again. Saying that future code may ruin the dependencies of the proposed library is like suggesting that future code may cause shared_ptr to leak memory. That's true, but it doesn't stop us from designing a class that manages memory without leaking.

> Lumping together unrelated code because it happens to fit the
> dependency graph could easily result in a mess which makes no logical
> sense. Reducing dependencies between header-only libraries is not that
> important a concern.
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost