Re: [boost] [Boost-users] Maintenace Guidelines wiki page

Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-11-25 21:31:06

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.

Daniel Walker