Re: [boost] hash_fwd dependency

Subject: Re: [boost] hash_fwd dependency
From: Daniel James (dnljms_at_[hidden])
Date: 2014-06-08 08:05:56

On 8 June 2014 12:33, Peter Dimov <lists_at_[hidden]> wrote:
> Daniel James wrote:
>>
>> On 7 June 2014 17:41, Peter Dimov <lists_at_[hidden]> wrote:
>> > While the general subject of forwarding headers still deserves >
>> > consideration, in this specific case I wonder if moving funcional/hash >
>> > into its own 'hash' module would not alleviate most of the problem.
>>
>> The point of the forwarding header was to be a lightweight header, because
>> the main header is quite heavy, so separating out the forwarding header is
>> probably the right thing to do.
>
>
> It's definitely the right thing to do.
>
> This doesn't mean that splitting 'hash' into its own module isn't also the
> right thing to do.

I didn't make that inference. If you look in the archives I wanted
hash to be a separate module before the conversion.

> That's what modularization means - to isolate independent components.

Well, I never! And I thought it meant arguing on mailing lists.

> 'hash'
> is completely independent of the rest of the functional library, it's even
> of a different kind.

Functional includes several disparate libraries.

>> Looking at your report, many of functional's dependencies seem to be
>> caused by problems elsewhere, e.g. boost/functional/factory.hpp includes
>> boost/pointee.hpp from iterator, which pulls in a lot of modules. I think
>> the problem there is with boost/pointee.hpp.
>
>
> boost/pointee.hpp, along with boost/indirect_reference.hpp and
> boost/detail/is_incrementable.hpp, are an obvious target, one that I've
> already identified. If you look at them, however, you'll see that they can't
> go to Core in their present form, as they have dependencies on MPL and
> TypeTraits. They will be dealt with, in due time.
>
> At the moment, I've been concentrating on (a) low-hanging fruits that (b)
> don't have potential to break code. 'pointee' and friends are neither.
> Splitting 'hash' into its own module is both. Separating hash_fwd could be,
> if we figure out where to put it, which I estimate will take time.

Why the rush? I've got enough things to deal with in this release, I
don't want to add another.