Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-12 15:57:10


"Jeff Garland" <jeff_at_[hidden]> writes:

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

Haven't a few people been reporting that they won't even begin to
apply this one because of particular limitations? Anyone who needs
higher performance won't even get started.

> Users suggest and submit enhancement ideas -- sometimes fully coded.

Nobody ever submitted me anything that could be thought of as a
progressive step towards the two major redesigns I've done
(Boost.Python and Boost.Iterators). The redesigns took a great deal
of imagination, the sort of thinking that someone who's just trying to
get his own work done can't really afford to do.

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

Yes.

>> > 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,
>> anyone.
>
> 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.

I don't understand why you're saying that. I made no judgement about
the health of the conversation.

> 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:
>
> http://www.boost.org/more/formal_review_schedule.html

I remember now, thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk