Re: [boost] How to review futures?

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-12 03:05:29

----- Original Message ----- 
From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, May 10, 2008 11:30 PM
Subject: Re: [boost] How to review futures?

> Douglas Gregor <dgregor_at_[hidden]> 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