|
Boost : |
From: Douglas Gregor (dgregor_at_[hidden])
Date: 2008-05-09 18:49:26
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk