From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-12 14:37:35
On Sat, 12 Mar 2005 12:39:14 -0500, David Abrahams wrote
> > Yes, I expect major changes over time. Many libraries in boost
> > have evolved
> > significantly over time as users adopt and run into issues that cannot be
> > fully anticipated in reviews. Iterator adaptors comes to mind as
> > a library that, in theory, it's current state could have been
> > fully analyzed up front.
> Well, it's not perfect yet, by any means.
Sure, but even the old 'bad design' was a useful advance.
> > But, in fact, it took usage and a major refactoring, including interface
> > changes, to get to the current design.
> Yes, and that was an *enormous* effort involving many months and
> three people. Major redesigns are very hard, and usually they seem
> to require the original library author to become extremely uncomfortable
> with the limitations and/or problems of the original design.
No question that (re)design is hard. One of the ways that authors get
uncomfortable is others apply the library in various projects and run across
report various limitations. Users suggest and submit enhancement
ideas -- sometimes fully coded. And, of course, this can happen even if the
library is rejected -- it's just that the user audience will be smaller. And
that assumes that Andreas would decide to continue working on it...
> > Filesystem is another evolving library
> > -- it solves real problems for many current users, but it doesn't do
> > everything people want.
> Yeah, but what we're talking about here probably involves more than
> just evolutionary development. The performance limitations of this
> design are built into the structure of the library, IIUC. And IIUC
> the author has given no indication he intends to address that issue
> other than by explaining that there's no way to do so while
> maintaining the other design goals. Please correct me if I'm wrong,
I haven't read every last word, of the reviews, but what I did read seemed
like a mostly healthy interchange of possible ideas and limitations with
various approaches. No matter the final implementation the fsm concepts and
background will stay the same. And perhaps the any new interface becomes
different interface. I'm unsure if the various approaches can be unified...
> I want to be clear that I don't have a vendetta against this library
> or its author. I do think it's important to be realistic about
> what's likely to happen to it if it's accepted.
Understood. There are basically 3 options from this juncture -- accept the
library unconditionally, reject, accept with limitations. I think what I was
hoping is that some sort of consensus could emerge which would allow a path to
acceptance with conditions that would satisfy the folks that want to reject
and would also work for Andreas. Ultimately it will be up to Pavel's judgement...
> Did I miss something? We reviewed a fixed-point decimal library??
Yes, in 2003. Mr Seymour choose to walk away after the library was rejected.
The history is here:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk