On Sun, Nov 23, 2008 at 1:01 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

----- Original Message ----- From: "Henrik Sundberg" <storangen@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, November 23, 2008 12:18 PM Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page

...

On Sun, Nov 23, 2008 at 11:29 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

...

The Daniel proposal implies some changes in the writing rights of the authors. I prefer to let this point out of these guidelines. Of course I think that this is a good idea.

I think this is absolutely wrong. The authors are the experts and they do all work. You should never try to make them inferior. Do not handle quality in Boost as in old fashioned handling of "Quality" (which *not* is the same as product/code quality) in big companies. There is a release management in Boost. The release manager can choose not to accept something in the release if something is considered to be too bad.

I have never said the contrary.

I'm sorry. I thought a restriction was meant with "changes in the writing rights of the authors". And I thought "Of course I think that this is a good idea" referred to that restriction. I agree with you to place such rules outside of the maintenance guidelines. But I think that all author restrictions will make fewer people interested in contributing to Boost. Subversion makes it fairly simple to revert changes. Fix problems when they have occurred instead. Back to what I misunderstood; what does "that" refer to in "Of course I think that this is a good idea"? /$

On Sun, Nov 23, 2008 at 2:37 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

Do you know if the author can change himself the permision on his own SVN files?

Subversion is not meant to be used that way, as I understand it. Locks would give the effect you describe, but they aren't meant to be used for this.

...

Back to what I misunderstood; what does "that" refer to in "Of course I think that this is a good idea"?

I think that is a good idea that the author do not change the released test files.

I don't think released files shall be changed at all. This should be prevented by hook scripts*).

If he thisnk that this is good, changing the write permission to these files will avoid to change them by error. I don't think that it is a good idea to make this a rule and improse this guideline to authors, but I would like they adopt this guideline because I really think that it helps them.

I think you say that files that has been copied to tags, shall not be edited in trunk. That seems like hindering development. I see no real difference between bugs/changes in test code and bugs/changes in C++ code.

I hope that it is clear that I don't want to impose any rule to the authors, release manager or users. Guidelines that are used could incite other to use them. If some of the guidelines seems no useful at all, I have no problem to remove them from this Maintenance Guidelines.

I think you're doing a very good thing by writing this guideline. I believe in guidelines too. I actually believe in some rules as well. /$ *) Adding rules that must be followed in the hook scripts is mostly good. But as always there are exceptions. In my repository I therefore accept all commits, no matter my own rules, as long as the commit comment begins with "ABUSE: ".

On Sun, Nov 23, 2008 at 6:18 AM, Henrik Sundberg <storangen@gmail.com> wrote:

On Sun, Nov 23, 2008 at 11:29 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

...

The Daniel proposal implies some changes in the writing rights of the authors. I prefer to let this point out of these guidelines. Of course I think that this is a good idea.

I think this is absolutely wrong. The authors are the experts and they do all work. You should never try to make them inferior.

Umm, I didn't say anyone was inferior to anyone else. I'm afraid you misconstrued my statement.

Do not handle quality in Boost as in old fashioned handling of "Quality" (which *not* is the same as product/code quality) in big companies. There is a release management in Boost. The release manager can choose not to accept something in the release if something is considered to be too bad.

This is a good comparison. Quality assurance in boost, or any open source project, won't be the same as QA in a corporate setting. (Incidentally, most corporations are much smaller than boost in terms of participates.) The release manager is boost's closest analogy to a corporate QA department. However, with more and more libraries, the release manager's job is getting harder and quality may slip as a result. Most open source projects have what (I believe) ESR called a benevolent dictator; i.e. one person or a small group of people who lead the project and have write permissions on the version control system. Contributors submit patches and the leader of the project guards the quality by deciding how changes are accepted. With boost, each library's authors are the benevolent dictators of that library. However, who are the leaders of boost as a whole? What power do they have to guard the quality of boost? Authors write their own tests (I'm not suggesting they shouldn't), and the community accepts them during the review. Once accepted, the tests should be a verification that the library does what the community voted on. The tests are a verification of quality. At that point, I think it might be a good idea to quarantine the tests, take them out of the authors hands, and put them under the stewardship of a benevolent dictator of boost as a whole so that they can be used to assure that the library does what the community voted on. But I don't know. Here's another idea. Rather than trying to make the analogy between boost and a single open source project, perhaps the analogy should be between boost and a single distributer of multiple open source projects, for example, Debain or Fedora. Debian, for example, has three tiers of "release": testing, stable, and unstable - everyone's favorite. ;) I'm not sure what quality control procedures they have, but maybe that's also a good place to look for ideas. Daniel Walker

Daniel Walker wrote:

I was just sitting here thinking that benevolent "dictator" is really not an apt term for what I'm talking about. I'm really talking about some sort of public servants who would represent the interests of the community of boosters. These benevolent representatives would perform the service of insuring the community's votes are adhered to from one release to the next by judiciously exercising the power of write permission for unit tests on svn. We could call them the "quality congress." ;) Or maybe committee is a better word. Or maybe we could just make this a function of the release manager, if he isn't already overburdened. Anyway, I guess you all get the idea.

LOL - getting into political philosophy here. This is totally the wrong approach and would consume enormous resources and stymy any attempt to actually get anything done - pretty much like the "real congress". The right model is that the author makes his library which reflects his own choices and values. The review process guarentees that it meets some consensus about minimun acceptable levels of utility, quality, etc. The it is unleashed upon the world as part of the "boost release". At this point, users review it in light of thier current needs. They might use it, they might complain about, they might do any number of things. One of the things they do is report on one of the lists. And this guides other users as to whether or not they expect to use it. We can see this process playing as we speak regarding boost range. Looks like its working pretty well to me. Robert Ramey

On Sun, Nov 23, 2008 at 3:25 PM, David Abrahams <dave@boostpro.com> wrote:

on Sun Nov 23 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

...

Daniel Walker wrote:

...

I was just sitting here thinking that benevolent "dictator" is really not an apt term for what I'm talking about. I'm really talking about some sort of public servants who would represent the interests of the community of boosters. These benevolent representatives would perform the service of insuring the community's votes are adhered to from one release to the next by judiciously exercising the power of write permission for unit tests on svn. We could call them the "quality congress." ;) Or maybe committee is a better word. Or maybe we could just make this a function of the release manager, if he isn't already overburdened. Anyway, I guess you all get the idea.

LOL - getting into political philosophy here.

This is totally the wrong approach and would consume enormous resources and stymy any attempt to actually get anything done - pretty much like the "real congress".

The right model is that the author makes his library which reflects his own choices and values. The review process guarentees that it meets some consensus about minimun acceptable levels of utility, quality, etc. The it is unleashed upon the world as part of the "boost release". At this point, users review it in light of thier current needs. They might use it, they might complain about, they might do any number of things. One of the things they do is report on one of the lists. And this guides other users as to whether or not they expect to use it.

We can see this process playing as we speak regarding boost range. Looks like its working pretty well to me.

Thank you, Robert. One of the reasons Boost exists is to be more nimble than any committee (particularly the C++ standards committee) can be.

That's true, but at the same time, one goal of boost, as I've understood it, is to establish existing practice, which could eventually lead to inclusion in the standard library. So, yes, boost should be more nimble than the ISO, but I think it should not be so fluid as to make the peer review process meaningless and undermine progress toward establishing best practices. Daniel Walker

On Sun, Nov 23, 2008 at 4:20 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

----- Original Message ----- From: "Daniel Walker" <daniel.j.walker@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, November 23, 2008 9:38 PM Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page

...

On Sun, Nov 23, 2008 at 3:25 PM, David Abrahams <dave@boostpro.com> wrote:

...

on Sun Nov 23 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

...

Daniel Walker wrote:

...

I was just sitting here thinking that benevolent "dictator" is really not an apt term for what I'm talking about. I'm really talking about some sort of public servants who would represent the interests of the community of boosters. These benevolent representatives would perform the service of insuring the community's votes are adhered to from one release to the next by judiciously exercising the power of write permission for unit tests on svn. We could call them the "quality congress." ;) Or maybe committee is a better word. Or maybe we could just make this a function of the release manager, if he isn't already overburdened. Anyway, I guess you all get the idea.

LOL - getting into political philosophy here.

This is totally the wrong approach and would consume enormous resources and stymy any attempt to actually get anything done - pretty much like the "real congress".

The right model is that the author makes his library which reflects his own choices and values. The review process guarentees that it meets some consensus about minimun acceptable levels of utility, quality, etc. The it is unleashed upon the world as part of the "boost release". At this point, users review it in light of thier current needs. They might use it, they might complain about, they might do any number of things. One of the things they do is report on one of the lists. And this guides other users as to whether or not they expect to use it.

We can see this process playing as we speak regarding boost range. Looks like its working pretty well to me.

Thank you, Robert. One of the reasons Boost exists is to be more nimble than any committee (particularly the C++ standards committee) can be.

That's true, but at the same time, one goal of boost, as I've understood it, is to establish existing practice, which could eventually lead to inclusion in the standard library. So, yes, boost should be more nimble than the ISO, but I think it should not be so fluid as to make the peer review process meaningless and undermine progress toward establishing best practices.

Robert, Daniel I'm sorry but, from which peer review process are you talking about? The review of the acceptation of a new library or ...

I'm speaking of the formal review for library acceptance.

The goal of a review been to ensure quality., you don't think that every major evolution of a Boost library should have its own mini-review?

That's a good question, and I really don't know the answer. Others know the history better than me, but I feel like when Boost started most libraries were already fairly mature at the time they were submitted for review; if they weren't they were rejected. After acceptance, must libraries were fairly stable, so existing practice evolved around boost and many of those early libraries are now in the ISO draft standard. But it's good to have major evolutionary changes, now and then. Boost.Iterator went through a major rewrite, Boost.Lambda is about to go through the same... But my impression is that the major changes should be rare, an exception that proves the rule, and should be handled as a special case. Daniel Walker

On Mon, Nov 24, 2008 at 9:38 AM, David Abrahams <dave@boostpro.com> wrote:

on Sun Nov 23 2008, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:

...

...

The goal of a review been to ensure quality., you don't think that every major evolution of a Boost library should have its own mini-review?

That's a good question, and I really don't know the answer. Others know the history better than me, but I feel like when Boost started most libraries were already fairly mature at the time they were submitted for review; if they weren't they were rejected. After acceptance, must libraries were fairly stable, so existing practice evolved around boost and many of those early libraries are now in the ISO draft standard.

But it's good to have major evolutionary changes, now and then. Boost.Iterator went through a major rewrite, Boost.Lambda is about to go through the same... But my impression is that the major changes should be rare, an exception that proves the rule, and should be handled as a special case.

Perhaps more importantly, major evolutionary changes have historically been handled well, without causing major pain to users.

I agree. Boost has a long history of success, and I certainly respect the accomplishments of all Boost authors. Daniel Walker

On Sun, Nov 23, 2008 at 6:21 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

The goal of a review been to ensure quality., you don't think that every major evolution of a Boost library should have its own mini-review?

I can see the motivation for such a proposal. But honestly I don't think that the problem is so large and/or so frequent that it warrents so much effort to avoid. Sometimes this is going to happen and I'm going to feel that I was snookered. It's a fact of life that I just have to accept and work around it. I don't think it can be prevented, all I can do is to make the library authors sorry they did it. Maybe that diminishes future occurences.

Well, yeah, that's a valid point. If trying to prevent this problem introduces bureaucratic overhead without actually preventing the problem, then it's not worth it. But if it's true that this problem is not so frequent and library test cases rarely change, then these quality assurance procedures would rarely be invoked. When they are, they may help avoid unnecessary destabilization by, if nothing else, introducing a little scrutiny, which never hurts really. Daniel Walker

On Mon, Nov 24, 2008 at 9:33 AM, David Abrahams <dave@boostpro.com> wrote:

on Sun Nov 23 2008, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:

...

...

One of the reasons Boost exists is to be more nimble than any committee (particularly the C++ standards committee) can be.

That's true, but at the same time, one goal of boost, as I've understood it, is to establish existing practice, which could eventually lead to inclusion in the standard library. So, yes, boost should be more nimble than the ISO, but I think it should not be so fluid as to make the peer review process meaningless and undermine progress toward establishing best practices.

Do you actually think the current peer review process is meaningless, due to the fluidity of our operations?

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 wish I could get someone to just start composing a page of best practices without jumping headlong into trying to impose constraints on our contributors. We haven't even tried making such guidelines available yet.

You're right. I just think of permissions on a version control system as a tool, more than a negative constraint, so that's the first idea I had. If more conservative changes to test cases are a result of self-discipline, which I often lack ;), or if it's computer aided, either way, it's probably a good thing.

I guess I don't think it would be unreasonable to ask the release managers, as guardians of release quality, to monitor changes to the tests when they are checked into the release branch.

Yeah, that's a good idea. And as you suggested before, if SVN/Track can help by sending e-mails, it might make the release manager's life easier. Daniel Walker

on Mon Nov 24 2008, Matthias Schabel <boost-AT-schabel-family.org> wrote:

This is a somewhat tangential thought, but ... what if each release of the Boost libraries was put into its own namespace, so we have code in

namespace boost_1_38_0 { ... }

rather than in namespace boost. Then, in end user code, you just need :

using namespace boost = boost_1_38_0;

It seems like this would allow certain deprecated Boost components (those that are not too strongly coupled to the rest of Boost) to be used at the same time as more recent components from other libraries :

using boost_1_32_0::iterator_range;

iterator_range<some_iterator> rng;

which might sidestep some of the recent iterator_range anarchy, and simplify other major transitions. N.B. I haven't really thought about the ramifications of doing this, so the idea might be completely unworkable in practice.

It also allows multiple versions of boost to exist in the same executable without ODR violations. The ability to configure boost that way would be most welcome. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

...

...

which might sidestep some of the recent iterator_range anarchy, and simplify other major transitions. N.B. I haven't really thought about the ramifications of doing this, so the idea might be completely unworkable in practice.

It also allows multiple versions of boost to exist in the same executable without ODR violations. The ability to configure boost that way would be most welcome.

While the above seems like it may be useful, I can also see some potential difficulties. We would probably need to try and come up with a set of guidelines for users and developers on how to best take advantage of such a system. Here are a few things that come to mind:

1) From the discussion here, it is clear that a lot of users are very flexible when it comes to upgrading to a new version of boost. As such, they would want to just keep writing boost::foo, so that when they upgrade, their code continues working without having to go through and change boost_X::foo to boost_Y::foo.

I think that the only change that would need to be made in most end- user code is a namespace alias: using namespace boost = boost_1_38_0; The advantage of this is that upgrading to a newer boost library will trigger a compile-time error. You also have self-documentation on the version of boost that was used to develop the code.

below make me think that having versioned namespaces is not an alternative to the new/stable release cycle (I don't think the original poster necessarily intended it to be).

Right, it was not my intent to say anything about the idea of flagging libraries new/stable (which I also agree seems like a good idea).

I also have to say I can't quite see how it would have solved my original problem with Boost.Range.

My understanding of your issue may be incomplete, but I imagined that you would just include the boost_1_32_0 headers in files relying on the old iterator_range behavior. This would allow you to continue to use that version of the code, while simultaneously using more recent versions of other boost libraries (as Dave pointed out). In fact, I was even thinking that previous releases of the libraries could be retrospectively altered with the new boost namespace policy and re-released to provide some backward continuity.

2) While having different boost versions in different namespaces will allow different versions to exist in the same executable, because they are not interchangable, there cannot be any interoperability.

That may be true, but it may be the case that you inherit some code that uses an older version of boost, and you would like to modify or extend part of that code with newer boost library facilities without having to mess with the older, tested code that already exists. By having unique namespaces, you can accomplish this relatively easily. The main issue I see is naming of header files : should the directory structure also be altered so that the headers are, e.g., #include <boost_1_38_0/units/quantity.hpp>? This seems safest, but imposes some additional overhead.

a) The different parts of the executable (e.g. your code and the vendor library) use a disjoint subset of boost. Possible, but seems unlikely.

I actually think that this is fairly probable, since larger projects/ vendor supplied libraries generally are (for good reasons) slow adopters, if you want to use one of the shiny new boost libraries without breaking the vendor code, having the namespace separation would be nice.

I think the plug-in case may be important enough to make this change. I've had some other middle-of-the road ideas but I think we are already talking about introducing a big burden on the developers here.

The real issue is how can this be done in a way that minimizes the impact on both developers and end-users. It seems like some clever preprocessing could help ease the transition... Matthias

David Abrahams wrote:

on Mon Nov 24 2008, Matthias Schabel <boost-AT-schabel-family.org> wrote:

...

This is a somewhat tangential thought, but ... what if each release of the Boost libraries was put into its own namespace, so we have code in

namespace boost_1_38_0 { ... }

rather than in namespace boost. Then, in end user code, you just need :

using namespace boost = boost_1_38_0;

It seems like this would allow certain deprecated Boost components (those that are not too strongly coupled to the rest of Boost) to be used at the same time as more recent components from other libraries :

using boost_1_32_0::iterator_range;

iterator_range<some_iterator> rng;

which might sidestep some of the recent iterator_range anarchy, and simplify other major transitions. N.B. I haven't really thought about the ramifications of doing this, so the idea might be completely unworkable in practice.

It also allows multiple versions of boost to exist in the same executable without ODR violations. The ability to configure boost that way would be most welcome.

Let's take this to its logical conclusion: suppose that there exists spirit160 (works with borland), spirit180, and just spirit(might not work for me) - the latest version Then I could say: ? namespace boost { #if BORLAND using namespace spirit = sprit_160 // too old for most compilers #elseif TESTING using namespace spirit = spirit// too new for most compilers #else using namespace spririt = spirit_180 // just rig #endif ... } To be able to maintain stuffworking in an environment where libraries have broken their original interfaces would be most welcome. Of course only the lastest would need testing on a regular basis. Robert Ramey

Roland Schwarz wrote:

I have written a little perl script 'renamespace' that can be used to rename a namespace identifier for a single file or a whole project tree. The script is attached to this mail and is self-documenting. Just execute it with --help option to learn more.

The script has a special short-hand mode to version an entire boost tree. In addition it modifies two boost files: version.hpp and config.hpp. The first gets an additional macro BOOST_VERSIONED_NAMESPACE and the other is modified with a namespace alias (which can be turned off by the user if needed.) The net result is that it is possible with no change to the user code to build against this versioned boost tree.

One caveat: User code that needs to reopen the boost namespace has to reopen the versioned namespace of course. (This can be automated with some additional macros in the user code.) One typical case where this will be necessary is when using the serialization library.

I've put the script under the boost license, so if you think it is useful I would be glad to contribute it to the tools directory.

This is really cool. I have also had to solve this problem before. I managed to get away with /Dboost=boost_133_1 since it was on a small subset of Boost on a specific compiler. I will use your script next time I have to solve this problem properly. Please add it :-) -- Sohail Somani http://uint32t.blogspot.com

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. This does not include finding any statements about changing the behavior of is_singular(), but those changes may have been made when he was making other, announced breaking changes. (I would have to study the check in information to find this out, and I haven't this evening.) So, though you may have preferred the old concepts, others thought them fatally flawed (and I find their arguments persuasive). 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. John

"Daniel Walker" <daniel.j.walker@gmail.com> wrote in message news:a733b05a0811251831j57cd6403yc64f00af9b56a6bf@mail.gmail.com...

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)).

Daniel, I just ran into this problem today, while trying to fix some of the code that broke because of the 1.35 changes. The specification of size() has changed from 1.33.1 to 1.37, presumably in 1.35. In 1.37, it requires RandomAccessRange while in 1.33.1 it only needs ForwardRange. This is not a terribly difficult problem for me to fix but it's another breaking change. I think the library is trying to enforce certain performance requirements. IMHO, the restrictions should be enforced by the library user, not the library itself. Since I wasn't involved in the original design, I have a question though: Did the original design require that each Range be at least Bidirectional? The requirement of rend() and rbegin() is telling me that was. What am I missing? Thanks, Tom

"Daniel Walker" <daniel.j.walker@gmail.com> wrote in message news:a733b05a0811251934v5081827uf145e7aca1dd4ce8@mail.gmail.com...

I'm looking at the 1.37 docs right now and I don't see size(r). It should be here http://www.boost.org/doc/libs/1_37_0/libs/range/doc/range.html#forward_range

Yes, I was agreeing with that. I was referring to the change of description of size() on http://www.boost.org/doc/libs/1_37_0/libs/range/doc/headers.html vs http://www.boost.org/doc/libs/1_33_1/libs/range/doc/headers.html

If you're using it at all, it's not part of the concept definitions. So formally, you can't assume that all types modeling ForwardRange support it.

I was just reinforcing your point and showing that it was another case where the new Range broke my code.

size functions usually only require ForwardIterators, though the implementation is more time efficient for RandomAccess. See std::distance().

Of course. Again, I was in agreement and just ruing the change. It just means I just had to go and re-implement the old behaviour myself, and changing the locations using it. Tom

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

Quoting Daniel Walker <daniel.j.walker@gmail.com>:

On Tue, Nov 25, 2008 at 1:57 AM, John Phillips <phillips@mps.ohio-state.edu> 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.

Hi, please quote to who you are replying. ----- Original Message ----- From: "Tomas Puverle" <Tomas.Puverle@morganstanley.com> To: <boost@lists.boost.org> Sent: Tuesday, November 25, 2008 6:17 AM Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page

...

Do you actually think the current peer review process is meaningless, due to the fluidity of our operations?

I wish I could get someone to just start composing a page of best practices without jumping headlong into trying to impose constraints on our contributors. We haven't even tried making such guidelines available yet.

I think one of the issues why we may be seeing a problem is that boost is a different library than it was a few years ago. The number of new libraries has grown significantly and some of them are becoming quite high level and domain specific. However, most new libraries don't get much exposure until they are officially released by boost and as such are subject to more change than older, more established libraries. That in turn also means that new libraries should be allowed more flexibility in their evolution, as their user base is smaller. Dave Handley and I have already mentioned this a few times in one of the other threads but nobody really responded. Daniel Walker also suggested a model similar to what Debian or Ubuntu do, which has some similarity, so I'm trying to resurrect it the idea. I think the guidelines should be ultimately tied to the concept of the "stable" versus "evolving" libraries.

Here's the original post describing the perceived advantages of this approach:

http://article.gmane.org/gmane.comp.lib.boost.devel/182741/match=core

IMO, the guidelines match quite well with your concept of "stable" libraries. DW :"All changes to "stable" have to go through a review and cannot be brought in a single release - they must be deprecated and a migration path provided." In the guidelines I'm writing I want to give some good practive that make a library stable, i.e. don't breack user code, this seems very important for a lot of people. Don't forget my first question before starting this guidelines. VBE: " I would like to know first which are the current criteria for acceptance of library modifications, in order to make a clear difference on what *must* be done and what *could* be done. Can some one point me to some written document?" DA: "There are no set criteria. All modifications are at the discretion of the library maintainer." The single difference between the guidelines and the "stable" library concept is that some of these "guidelines" are "rules" instead. BTW, I'll add the migration path on the guidelines. Write these good practice in the form of "Guidelines" will be IMO a good starting point. The time been, good practices that are widely shared becomes often 'de facto' rules. Best, Vicente

----- Original Message ----- From: "Michael Marcin" <mike.marcin@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, November 25, 2008 6:58 PM Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page

Tomas Puverle wrote:

...

I think the guidelines should be ultimately tied to the concept of the "stable" versus "evolving" libraries.

IMO stable = stale.

I would hope that all boost libraries would be constantly evolving.

Constant evolution and stable libraries are not contradictory. Stable libraries impose a constant evolution but no revolution. Vicente

Hey Robert, "Robert Ramey" <ramey@rrsd.com> wrote in message news:gghocm$482$1@ger.gmane.org...

My take on this whole question is a lot different. In the quest for excellence - which libraries are you going to set aside?

If by that you mean "Which libraries should be marked as 'Stable'", I think it would be easy to identify a few which are going to be use by almost anyone: Shared ptr, range, iterators,... Of course, differrent people will have different set functions but that's the discussion I'm trying to initiate.

And I might use a library that is less than what I want in some aspect because it's still better than rolling my own.

Of course. That is actually a big reason why I'm proposing the split release schedule. We'd love to use some of the newer libraries but can't, because they are only available with the "full" releases of boost.

So the idea of imposing more and more infrastructure to get better quality wouldn't work.

I don't know that we can impose "more quality". To their credit, for most part that job is already being done very well by the developers here. I would use the phrases "predictability" and "easier upgrade path" to describe what I'm looking for.

And if implemented would result in a smaller number of useful libraries being available to those of us that need them.

I am not sure if you are referring to my comments in particular, but please let me know what are your concerns so I can address them. I think what I'm saying implies the complete opposite - making more libraries available to more people.

What I really need is a better way to assess the library along the above dimensions. Making this type of information publically available would help me decide which libraries to consider and would let authors know what they need to address to make their libraries more popular. <Rest of description snipped>

That sounds interesting. I wonder though if such critique may bruise a few egos and have the opposite effect of having them give up on the project? Also, if a library went through a major change/redesign, how would the new scores reflect this? Tom

IMO stable = stale.

I would hope that all boost libraries would be constantly evolving.

I am not sure if you read my post but the two concepts are not mutually exclusive. I expect you wouldn't be too happy if the next release drastically altered the behaviour of shared_ptr, yes? I would like to have some warning and perhaps a transition period. I think the "stable" libraries are well established and rarely change anyway - and that's the user's expectation, too. Hence if they were to change drastically, it would take people by surprise. I was trying to suggest that when changing them, it should be done with more care than for some of the newer libs, which would be allowed more flexibility. The second part of what I'm saying is, IMHO, applicable to any large corporate environment. You really want to use a newly accepted/released library X but you can't, because your firm is stuck on boost version neanderthal. If new libraries could be released in incremental releases that don't necessarily alter the core components of boost, it would be much easier to introduce them to such environments. Each new version of boost means rebuild the world and that's not feasible, unless it's also part of some major internal release. Furthermore, now you've introduced several new variables into the new build and limiting the number of moving parts is IMHO a good idea. These internal rebuilds don't happen too often, and this in turn is giving new boost libraries less exposure than they could have. There were a few other reasons I wrote about in the link provided but the two above are the major ones. Tom