First, the big question I vote for a second fast track review of the v3 implementation. The reasoning is simple, if a little painful. I have a lot of sympathy for the view that we should be reviewing the version that is actually going to be released (or at least something close to it). Joel is right that some libraries have been admitted with the condition of large changes. In general, given the exceptional quality of his work to date, I also consider him quite trustworthy when he says that is what he plans to do. However, I have problems with how I'm supposed to review the implementation of a library that won't be implemented the same way when it goes into Boost. That said, even the v2 edition is an exceptional library. It has been pointed out elsewhere that there are some current details missing from v2, and Joel has already promised their inclusion in v3. Aside from those artifacts of its history, it is a very nice piece of work. I have used it in a few projects and I find it clear to use, well documented and largely well behaved (except for afore mentioned problems). It works on compilers that live close enough to the standard, and that happens to be what I currently use. It is well documented (I also vote for the return of the section on FP.), and I enjoy the style. There is a lot to learn to use the library well, but that is partially because it is a powerful library in a programming idiom that many of us have only learned we need recently. It is practical, and so provides a gentler step into functional programming than would be the case if it stressed purity. However, it allows clearly functional constructs and has well thought out abstractions underlying the interface The reasoning is painful because it has me voting against immediate inclusion for a library I obviously like and respect. However, I think this review is valuable for what it accomplishes. In my following of the discussion so far, I haven't seen anyone who has issues with the need for the library, with the basics of the interface, or with the abstractions it embodies. I think this is the 85% good stuff (I may be remembering the wrong number here.) that Joel spoke of. That allows us to focus the fast track I am voting for on the implementation and compliance with a few specific changes. v2 will be available, and the small breaking changes in v3 will be the first boost release (since I'd be very surprised if Joel didn't do all requested and more for v3), so there will be a minimal legacy code base issue. As for the naming, I would also like to see the release version become the new Lambda v2. Though I appreciate creative names for some things, it seems to cause problems for software libraries. John Phillips
John wrote:
First, the big question
I vote for a second fast track review of the v3 implementation.
The reasoning is simple, if a little painful. I have a lot of sympathy for the view that we should be reviewing the version that is actually going to be released (or at least something close to it). Joel is right that some libraries have been admitted with the condition of large changes. In general, given the exceptional quality of his work to date, I also consider him quite trustworthy when he says that is what he plans to do. However, I have problems with how I'm supposed to review the implementation of a library that won't be implemented the same way when it goes into Boost.
Understood.
That said, even the v2 edition is an exceptional library. It has been pointed out elsewhere that there are some current details missing from v2, and Joel has already promised their inclusion in v3. Aside from those artifacts of its history, it is a very nice piece of work. I have used it in a few projects and I find it clear to use, well documented and largely well behaved (except for afore mentioned problems). It works on compilers that live close enough to the standard, and that happens to be what I currently use. It is well documented (I also vote for the return of the section on FP.), and I enjoy the style. There is a lot to learn to use the library well, but that is partially because it is a powerful library in a programming idiom that many of us have only learned we need recently.
It's reasonable to have more background on FP in the docs. I'm an advocate of it anyway, so I'll be pleased to provide more material on the subject -- at least the practical side of FP.
It is practical, and so provides a gentler step into functional programming than would be the case if it stressed purity. However, it allows clearly functional constructs and has well thought out abstractions underlying the interface
The reasoning is painful because it has me voting against immediate inclusion for a library I obviously like and respect. However, I think this review is valuable for what it accomplishes. In my following of the discussion so far, I haven't seen anyone who has issues with the need for the library, with the basics of the interface, or with the abstractions it embodies. I think this is the 85% good stuff (I may be remembering the wrong number here.) that Joel spoke of. That allows us to focus the fast track I am voting for on the implementation and compliance with a few specific changes.
v2 will be available, and the small breaking changes in v3 will be the first boost release (since I'd be very surprised if Joel didn't do all requested and more for v3), so there will be a minimal legacy code base issue.
As for the naming, I would also like to see the release version become the new Lambda v2. Though I appreciate creative names for some things, it seems to cause problems for software libraries.
Thank you for your review. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
participants (2)
-
Joel de Guzman -
John