Re: [boost] [modularization] Modularizing Boost (modularization)

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-10-19 00:43:09

On Oct 18, 2013, at 1:04 PM, Edward Diener <eldiener_at_[hidden]> wrote:

> On 10/18/2013 12:37 PM, Stephen Kelly wrote:
>> On 10/18/2013 06:28 PM, Edward Diener wrote:
>>> On 10/18/2013 11:59 AM, Stephen Kelly wrote:
>>>> On 10/18/2013 05:42 PM, Edward Diener wrote:
>>>>> 
>>>>> The property_map library can be used completely outside of the graph
>>>>> library. What does moving parts of property_map into graph accomplish ?
>>>> 
>>>> It makes the property_map library/repo/package not depend on the graph
>>>> library/repo/package.
>>> 
>>> The property_map library is a header only library. Please point out to me where in the property_map headers there is any reference to anything in the graph library.
>> 
>> Le-sigh.
>> 
>> I suggest you do your equivalent of this:
>> 
>>  boost-trunk/boost/property_map{master}$ git grep boost/graph
>> 
>> I won't ruin the surprise for you by pasting the output.
>> 
>> If you don't understand my point after seeing the output, please just accept that you don't understand the point. No need to respond. A long
>> sub-thread like this is bad.
> 
> No a sub-thread like this is not bad. When you feel entitled to do things without valid justification that is bad. And when you talk in condescending terms to others that is bad. If you cannot or are unwilling to explain and defend the reasons why you are doing what you are doing in terms of Boost libraries/files I for one don't think you should be able to do those things.

I've been following a number of Steve's threads. What I've observed is that Steve's replies, to those that disagree or stymie his progress, grow increasingly uncivil. Perhaps Steve doesn't realize how easy it is to miss entire threads on this high volume list. Perhaps he doesn't realize that many maintainers filter on their name and library tags to spot messages and threads of interest, which means many can join a discussion long after it began. This can often slow or thwart progress, especially if the late arrivals do not read the entire thread and rehash some points. Nevertheless, those are facts of how this list works.

Decreasing unnecessary coupling among Boost libraries is laudable, but shouldn't be rushed. Instability from such changes can be worse than living with the coupling, for the maintainer anyway. Patient, reasoned answers will go a long way toward building consensus. Snippy and condescending responses will have the opposite effect.

Removing workarounds for ancient compilers required touching a great many files. However, those changes could have been committed one library at a time, with config being last (removing the macro once no longer referenced). Similarly, removing cycles from the dependency graphs can be addressed one library at a time. That permits dealing with one maintainer at a time. (Moves between libraries means another maintainer, of course.) When all such changes have been done, the result will be the same, but the process will be less alarming, though perhaps longer and more troublesome.

Anyway, rather than butting heads, I suggest that Steve build cooperation, one maintainer at a time. The path may be longer, but arriving at the desired goal is more likely.

___
Rob

(Sent from my portable computation engine)