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

Subject: Re: [boost] range -> algorithm, Was: [modularization] Recommendations
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-09 07:59:09

Le 09/06/14 13:25, Neil Groves a écrit :
> 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.
Neil I think that the most urgent is in removing the dependencies that 
make cycles. Once this is done, xe could refactor more if this makes 
Boost more manageable.
> 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?
You could always fork and do pull requests, even if this is not optimal.
> 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.
>
>
I think it is enough you request to be a member of the community 
maintenece team explicitly.

Thanks,
Vicente