Daniel Walker skrev:
On Mon, Nov 24, 2008 at 9:28 AM, David Abrahams <dave@boostpro.com> wrote:
on Sun Nov 23 2008, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:
As for contributing to Boost, people are also deterred when they take the time to understand a library and submit improvements to it, only to have the rug pulled out from under them. This is actually my personal experience with Boost.Range. The Range concepts used to have an empty(r) that I believe addressed the issue of empty ranges independently of iterator_range. But the whole thing falls on its face when for no sensible reason the function was removed from the concept definition. Why should I use the new Range concepts, let alone contribute to the library, if these are not even the concepts that were released after review and acceptance for boost? I mean, I'm not throwing in the towel, I'm just expressing my frustration, not only as a user but as a contributer.
Rather than set up systems that will decrease agility, increase coupling, and give contriutors the sense that the Boost community doesn't trust them to do what's right, suppose we set up a mailing list to which all the test checkins are posted? Then anyone who wants to monitor the evolution of a library's tests can subscribe to that list.
I think this is a good idea, and in principle I could support it. However, I must point out that it brings up another issue: Individuals in the Boost community have some responsibility for monitoring Boost development. If I had been paying closer attention, I could have protested the changes in the Range concepts a long time ago.
Daniel, I just want to reiterate something. It is true that there was no second review of the new concepts and that the change could have been announced better. But the change was far from accidental, and was not only motivated by my wish to break peoples code (ironi), but came about because users of the library had great troubles with the original concepts. We had lengthy discussion here on the list. Eric Niebler initiated some of them because he was trying to use boost.range in Boost.for_each. Although you might be of a different opinion, then it was not without sensible reason to remove empty() from the concepts. The new concepts are much clearer, and let us define empty as boost::empty(r) without imposing additional concept requirements. The library changed after its original form, and into something much better. And the change was motivated by real user feedback, something which the original review in some sense could not provide as much of. best regards -Thorsten