I'm looking to see if there are any good ideas for how to review the two futures libraries that are both currently in the queue. Since they are two different approaches to the same problem domain, isolated sequential reviews does not seem to be a good idea. So far, the best thought I've had on the subject is to run a single review that includes both libraries, where it is explicitly part of the review to discuss which parts of which realizations are the best choice. This process will need to keep the proposals before the committee in mind, but it is a way to compare and contrast the strengths of the two in close proximity. If we do this, there are a couple of questions that should be added to the usual review process. * Which interface choices are best suited to the problem domain? * Should Boost offer competing implementations of this feature? * Should the libraries be melded together? * Should a subset of the approved library be restricted to only the facilities and interface in the standardization committee proposal? There are my initial thoughts. I would like to hear from others on this, as well. I especially would like to hear from the authors and from anyone who has been involved in the evolving standards proposal. Thanks for your ideas. John Phillips Review Wizard
John Phillips wrote:
I'm looking to see if there are any good ideas for how to review the two futures libraries that are both currently in the queue. Since they are two different approaches to the same problem domain, isolated sequential reviews does not seem to be a good idea.
So far, the best thought I've had on the subject is to run a single review that includes both libraries, where it is explicitly part of the review to discuss which parts of which realizations are the best choice. This process will need to keep the proposals before the committee in mind, but it is a way to compare and contrast the strengths of the two in close proximity. If we do this, there are a couple of questions that should be added to the usual review process.
* Which interface choices are best suited to the problem domain? * Should Boost offer competing implementations of this feature? * Should the libraries be melded together? * Should a subset of the approved library be restricted to only the facilities and interface in the standardization committee proposal?
There are my initial thoughts. I would like to hear from others on this, as well. I especially would like to hear from the authors and from anyone who has been involved in the evolving standards proposal. Thanks for your ideas.
Just wanted to make a point that we may have a similar situation with the logging library if I manage to finish it before John's review starts. I do agree that the best solution would be either a single review or two parallel reviews. The second way is better for the reviews can be managed by different managers which splits the workload between them. However, I've never managed a review and I don't know if that would be possible/reasonable.
On May 9, 2008, at 2:05 PM, John Phillips wrote:
I'm looking to see if there are any good ideas for how to review the two futures libraries that are both currently in the queue. Since they are two different approaches to the same problem domain, isolated sequential reviews does not seem to be a good idea.
That's an interesting problem. I don't think we've ever had two potential libraries address the same application domain that are in the review queue at the same time. We certainly have some libraries in Boost with significant overlap (Regex-Xpressive, Lambda-Bind- Phoenix), but they came in at different times and each new library had something that the previous libraries didn't.
So far, the best thought I've had on the subject is to run a single review that includes both libraries, where it is explicitly part of the review to discuss which parts of which realizations are the best choice. This process will need to keep the proposals before the committee in mind, but it is a way to compare and contrast the strengths of the two in close proximity.
That's an interesting idea. I would like to hear from the authors of the libraries, because I'm guessing that this puts quite a bit of pressure on them... the end result is very likely to be a merger of the best ideas from both libraries, so they'll need to work together.
If we do this, there are a couple of questions that should be added to the usual review process.
* Which interface choices are best suited to the problem domain? * Should Boost offer competing implementations of this feature?
Ideally, I think Boost would not offer competing implementations in the same domain. Choice can be good, but it can also be confusing for users.
* Should the libraries be melded together?
I think this is very, very likely.
* Should a subset of the approved library be restricted to only the facilities and interface in the standardization committee proposal?
Absolutely not. If we can do better than the committee proposal, let's do it and send the results to the C++ committee for consideration. - Doug
Douglas Gregor <dgregor@osl.iu.edu> writes:
On May 9, 2008, at 2:05 PM, John Phillips wrote:
So far, the best thought I've had on the subject is to run a single review that includes both libraries, where it is explicitly part of the review to discuss which parts of which realizations are the best choice. This process will need to keep the proposals before the committee in mind, but it is a way to compare and contrast the strengths of the two in close proximity.
That's an interesting idea. I would like to hear from the authors of the libraries, because I'm guessing that this puts quite a bit of pressure on them... the end result is very likely to be a merger of the best ideas from both libraries, so they'll need to work together.
I think a joint review is a very good idea. I think there should only be one boost.futures library, and both our libraries offer slightly different perspectives, so they should be discussed together and the "best" interface chosen, which may be entirely new, but likely contains elements from each.
If we do this, there are a couple of questions that should be added to the usual review process.
* Which interface choices are best suited to the problem domain? * Should Boost offer competing implementations of this feature?
Ideally, I think Boost would not offer competing implementations in the same domain. Choice can be good, but it can also be confusing for users.
Agreed.
* Should the libraries be melded together?
I think this is very, very likely.
Agreed.
* Should a subset of the approved library be restricted to only the facilities and interface in the standardization committee proposal?
Absolutely not. If we can do better than the committee proposal, let's do it and send the results to the C++ committee for consideration.
Totally agreed. The proposal hasn't been approved by the committee yet, and part of my drive in implementing it is to get feedback before it is approved by the committee. We want to standardize the best interface we can get in the time available. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
----- Original Message ----- From: "Anthony Williams" <anthony_w.geo@yahoo.com> To: <boost@lists.boost.org> Sent: Saturday, May 10, 2008 11:30 PM Subject: Re: [boost] How to review futures?
Douglas Gregor <dgregor@osl.iu.edu> writes:
On May 9, 2008, at 2:05 PM, John Phillips wrote:
So far, the best thought I've had on the subject is to run a single review that includes both libraries, where it is explicitly part of the review to discuss which parts of which realizations are the best choice. This process will need to keep the proposals before the committee in mind, but it is a way to compare and contrast the strengths of the two in close proximity.
That's an interesting idea. I would like to hear from the authors of the libraries, because I'm guessing that this puts quite a bit of pressure on them... the end result is very likely to be a merger of the best ideas from both libraries, so they'll need to work together.
I think a joint review is a very good idea. I think there should only be one boost.futures library, and both our libraries offer slightly different perspectives, so they should be discussed together and the "best" interface chosen, which may be entirely new, but likely contains elements from each.
If we do this, there are a couple of questions that should be added to the usual review process.
* Which interface choices are best suited to the problem domain? * Should Boost offer competing implementations of this feature?
Ideally, I think Boost would not offer competing implementations in the same domain. Choice can be good, but it can also be confusing for users.
Agreed.
* Should the libraries be melded together?
I think this is very, very likely.
Agreed.
* Should a subset of the approved library be restricted to only the facilities and interface in the standardization committee proposal?
Absolutely not. If we can do better than the committee proposal, let's do it and send the results to the C++ committee for consideration.
Totally agreed. The proposal hasn't been approved by the committee yet, and part of my drive in implementing it is to get feedback before it is approved by the committee. We want to standardize the best interface we can get in the time available.
How many time do we have? When the review should take place to have time to write a new submission? Anthony, do you intend to write this submission following the results of the review? Before the review I think that it will be interesting that Antony and Braddock present separately or jointly, the advantages and liabilities of each library. Best, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
From: "Anthony Williams" <anthony_w.geo@yahoo.com>
Douglas Gregor <dgregor@osl.iu.edu> writes:
On May 9, 2008, at 2:05 PM, John Phillips wrote:
* Should a subset of the approved library be restricted to only the facilities and interface in the standardization committee proposal?
Absolutely not. If we can do better than the committee proposal, let's do it and send the results to the C++ committee for consideration.
Totally agreed. The proposal hasn't been approved by the committee yet, and part of my drive in implementing it is to get feedback before it is approved by the committee. We want to standardize the best interface we can get in the time available.
How many time do we have? When the review should take place to have time to write a new submission? Anthony, do you intend to write this submission following the results of the review?
The next mailing deadline is this coming Friday (16th May), so there is not time for a full review before then. I will submit a paper with my revised interface, potentially including any further comments received this week. The actual WG21 committee meeting is 8th-14th June, so there is potential that any further revisions received by then can be discussed. Beyond that, I'm not sure what scope we've got. I'm happy to keep submitting revisions until the LWG tell me that enough is enough, but as I understand it we need the working draft to be done by the end of the following meeting (14th-20th September) in order to get through the full ISO voting process in 2009. That means that the committee is going to be very restrictive of the changes they accept: only revisions to already-accepted functionality will even be considered. If C++09 doesn't contain everything from boost.future (whatever it looks like), there's always TR2.
Before the review I think that it will be interesting that Anthony and Braddock present separately or jointly, the advantages and liabilities of each library.
I think that would be a worthwhile exercise. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
----- Original Message ----- From: "Anthony Williams" <anthony_w.geo@yahoo.com> To: <boost@lists.boost.org> Sent: Monday, May 12, 2008 10:01 AM Subject: Re: [boost] How to review futures?
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
How many time do we have? When the review should take place to have time to write a new submission? Anthony, do you intend to write this submission following the results of the review?
The next mailing deadline is this coming Friday (16th May), so there is not time for a full review before then. I will submit a paper with my revised interface, potentially including any further comments received this week.
The actual WG21 committee meeting is 8th-14th June, so there is potential that any further revisions received by then can be discussed.
Hello Anthony, Which documentation do you plan to provide for your future review? I think that a reference to the C++ proposal(s) is not enough :-) Best, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Hello Anthony,
Which documentation do you plan to provide for your future review? I think that a reference to the C++ proposal(s) is not enough :-)
You're right, of course, especially since my current proposal doesn't match the existing paper. I'll write up some docs. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
participants (5)
-
Andrey Semashev -
Anthony Williams -
Douglas Gregor -
John Phillips -
vicente.botet