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

Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page
From: John Phillips (phillips_at_[hidden])
Date: 2008-11-25 23:17:26

Daniel Walker wrote:
> 
> 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

   Daniel,

   First, I pointed out in the previous that I did not see mentions of 
is_singular() in the past threads. However, here are some threads to 
look at if you want more details on the discussion. It totals to several 
dozen posts and I'm afraid I would not do them justice if I tried to 
summarize. However, there are also connections to other threads on the 
user list that discuss related problems of how to provide extension 
points in generic libraries. This does include some discussion of 
begin(), rbegin() and related. It also includes extended discussions of 
the concepts and problems with them.

[boost.range] post-review
[range] Collection Concept
[boost.range] renaming empty() to is_empty()
[boost.range] late addition, votes needed
[boost.range] RFC on small updates
[range] rationale for transform_range() algorithm?
[range] update on ADL hooks
[range] breaking changes
[Range] issues
char[] support in Boost.Range
Boost.Range Questions
Boost.Range naming
[Range] No Reply?
[range] How to extend Boost.Range?
[range] Inconsistent range_iterator metafunction
[Range] breaking update pending
[Range] upgrade in cvs
Problem with range?

   There are others, but you get the idea. This is all prior to the 1.35 
release. (There have been more threads since then, but you were involved 
in some of them so I would expect that you understand them better than I do.

   There are so many threads and so many posts that I can't even 
remember when it was pointed out that the concept for a range says that 
the requirement for a range is that end() be reachable from begin(). If 
this is so, then you can't guarentee computability for size() (This is a 
halting problem, after all.), so it is a questionable addition.

   There is a discussion in the above where Thorsten is advised that 
when he makes breaking changes he needs to determine whether the new and 
old interfaces can coexist, and if they cannot he will have to bite the 
bullet and break things.

   So, can I provide arguments for all of the changes? No, I cannot. In 
some cases they are reasonable, and in others they are not, as far as I 
can tell. However, I agree with those that hold that we need a clearer 
understanding of the concepts and how they interact. I realize you have 
spent time on concept checks for the library and so you have though 
about them more than I have.

   Once the concepts are well defined and understood, then the 
discussion of what is the proper interface to express them makes more 
sense. Then the documentation needs to become a clear statement of the 
interface and promises of the library. I know some posters in this 
thread find this annoying, but it is how we can create libraries that 
can be used by a large slice of the community.

                        John