Boost logo

Boost :

Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page
From: Peter Bartlett (pete_at_[hidden])
Date: 2008-11-26 04:30:06


Quoting Daniel Walker <daniel.j.walker_at_[hidden]>:

> On Tue, Nov 25, 2008 at 1:57 AM, John Phillips
> <phillips_at_[hidden]> wrote:
>> Daniel Walker wrote:
>>> In general, no, but in this specific instance, yes. At least, the
>>> Range concept definitions in the initial release immediately following
>>> the formal review are richer and more useful, IMHO, than the
>>> definitions available in the current release.
>>
>> I spent some time with the archives this evening, and I find that there are
>> dozens of emails from 2005, 2006, and 2007 talking about problems with the
>> concept definitions and documentation in the original version of the range
>> library. I also found a couple of different threads where Thorsten requested
>> advice on potential changes to the library, and where he announced breaking
>> changes to the library as a result of those conversations.
>
> I just did a search and found nothing. But good grief, let's not put
> each other on trial. Let's put the code, the designs and the
> development policies on trail.
>
> We have two specifications for the Range concepts that we can
> (objectively) compare. I maintain that the specification released
> after the formal review is clearly richer, offers more abstraction,
> and is more useful than the concepts available in the current release.
> In this instance, the changes in the library's concept definitions
> have resulted in a decrease in expressiveness and usability. The
> library would have benefited from guidelines aimed at stabilizing the
> initial release.
>
>> So, though you may have preferred the old concepts, others thought them
>> fatally flawed (and I find their arguments persuasive).
>
> If it's so fatal, name one problem that results from empty(r) being
> included in the Range concepts.
>
>> This is not to say that I think the changes that started this thread were
>> made properly. I can find no discussion on the developer list or note in the
>> documentation about the changes happening, and I think that is a minimal
>> standard for breaking changes. However, they may have been part of a
>> redesign that was precipitated by conversations on the developer list, and
>> other parts of that work were announced and discussed on the list. This
>> would imply that Thorsten was closer to an acceptable process than he is
>> currently getting credit for.
>
> Look, throwing blame this way and that is not going to get anywhere,
> and I apologize for ever adopting an accusatory tone. I was rather
> offended at the state of the Range concepts, and I may not have always
> used particularly diplomatic language. Then again, I consider candor
> to be courteous and a sign of respect. So, I'm not going to beat
> around the bush.
>
> Let's stick to the facts. The Range concept definitions went from
> supporting up to 6 procedural abstractions (begin(r), end(r),
> empty(r), size(r) rbegin(r), rend(r)) to supporting 2 (begin(r),
> end(r)). I would call that a 66% reduction in expressiveness. So I
> repeat, the Range concept definitions in the initial release
> immediately following the formal review are richer and more useful
> than the definitions available in the current release.
>
> More over, the current state of the Range concepts is indefensible. At
> least, no one has offered a defense. More specifically, no one has
> offered a response to the question of what problem is solved or what
> benefit is gained by removing empty(r) from the concept definitions. I
> gave a lengthy argument last night as to the benefits of empty(r). No
> one has countered it. Why should they? Emptiness or non-emptiness are
> natural, obvious attributes of a range. Why shouldn't a range
> abstraction such as a generic concept include a method for querying
> emptiness? It only makes sense.

Re "no-one has offered a defense". that could be because some of us
(well me, at least) are confused about the how big a problem you think
we we have. Are you saying you _can't_ check for emptiness with the
current requirements? But doesn't
boost::empty<SomeTypeModellingSinglePassRange>(r) do exactly that
(http://www.boost.org/doc/libs/1_37_0/libs/range/doc/boost_range.html)?

If you were arguing solely about possible performance loss by not
allowing a type to implement its own empty then I'd understand, but
you don't seem to be saying that.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk