Re: [boost] range -> algorithm, Was: [modularization] Recommendations

Subject: Re: [boost] range -> algorithm, Was: [modularization] Recommendations
From: Neil Groves (neil_at_[hidden])
Date: 2014-06-09 07:25:49

On Mon, Jun 9, 2014 at 11:49 AM, Peter Dimov <lists_at_[hidden]> wrote:

> Vicente J. Botet Escriba wrote:
>
>> Le 08/06/14 12:21, Stephen Kelly a écrit :
>> >
>> >
>> > Recommendation 3) Remove use of algorithm from range
>> >
>> > Range includes
>> >
>> >   boost/algorithm/string/config.hpp
>>
> ...
>
>> Hi,
>>
>> I agree with this modifications.
>>
>> Could we decide if this is the way to resolve this dependency?
>>
>
> Our general procedure should be that the decision if or when to resolve a
> dependency is up to the library maintainers.
>

I am a Boost.Range maintainer and I don't mind having the dependency moved
or removed. My delayed response is due to considering the way in which I
might assist best. I would like to improve the component breakdown and
hence modularisation effort. In addition to the dependency on algorithm, I
think Boost.Range would be improved by moving the algorithms into
Boost.Algorithm, and the tokenized adaptor should be moved into
Boost.Regex. Currently some C++11 algorithms are missing from Boost.Range
but present in Boost.Algorithm whereas C++03 algorithms all live inside
Boost.Range. I'd like to see Boost.Range become smaller and encourage other
components to provide range algorithms and adaptors. This is why the
richness of the Boost.Range adaptors is a little disappointing, I am not
keen on providing rich adaptors that couple other components. The adaptor
idiom should be adopted elsewhere. I don't want to do less to help Boost
and the lack of write access to other components makes this reorganisation
difficult for me to accomplish. Obviously I would wish to discuss and gain
support from the appropriate library maintainers, but the write access
issue is a barrier.

I believe that the strong rights to access to the component I am
responsible for combined with low rights to other components drives me
toward making design decisions that are suboptimal. I wonder if this has
the same effect with other developers. If so should we reconsider
re-enabling broader write access and encourage a less formal peer
collaboration?

I would like to join the community maintenance team and have broader write
access? I'd be delighted to help modularise Boost.Range and help out where
I can with other maintenance issues. Over the last few months I've been
able to dedicate significantly more time to Boost.

In summary, I'm happy to move aside to so that those working on the
modularisation effort can make progress. I am equally happy to directly
help.

Regards,
Neil Groves