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

Subject: Re: [boost] [modularization] Improving/splitting up detail
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-11-05 01:36:10

On Tue, Nov 5, 2013 at 10:17 AM, Gavin Lambert <gavinl_at_[hidden]> wrote:
> On 2/11/2013 22:47, Quoth Andrey Semashev:
>
>> There are things not intended for public use and yet useful for multiple
>> libraries. I don't think these components should be made a public part of
>> utility, but making them a private part of it seems ok to me.
>
>
> If something has proven useful for multiple Boost libraries, why wouldn't it
> be useful for application code?

Take a look at boost/detail contents. Except one or two headers, I
don't see why would someone need those things outside Boost.

> The only reason I can think of is simply that whoever wrote it doesn't want
> to pay the costs of documenting, reviewing, and at least somewhat preserving
> compatibility between releases -- but without documentation, review, and
> some kind of cross-release compatibility, why would any Boost library
> authors want to depend on it either?

All these are not big issues for internal components. The comments are
enough documentation and in case of incompatible changes all Boost
libraries can be updated relatively easily.

> Especially once Boost goes modular and a library author might make
> potentially breaking changes to some of the common code without even having
> downloaded some of the other libraries that depend on it (possibly thereby
> not realising the change was breaking, at least until the testers have
> cycled).

Modularization makes changes to common components more difficult, I
admit. But it doesn't mean these components should be made public.