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

Le 09/06/14 13:25, Neil Groves a écrit :

On Mon, Jun 9, 2014 at 11:49 AM, Peter Dimov 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