| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov | Sent: 25 October 2004 11:14 | To: boost@lists.boost.org | Subject: | | John Torjo wrote: | > | > It's so funny, during reviews, everyone comes up with his own better | > version of the reviewed library. For the proposer who has put in much work, it is not so funny ;-( | That's one of the reasons we have reviews, is it not? Better ideas are Boost's strength, but IMO review is the wrong time for radically better ideas - for they are often shooting from the hip, half-baked and in need of much more refinement. It seems wrong to me to have work which has been discussed and refined and tacitly used and accepted over a long time (necessarily waiting in the review queue) to be suddenly turned upside down at review, often by people who did not participate in the original discussions - a natural consquence of the quite rapid Boost membership turnover leading to 'Not Invented Here' syndrome. My impression is that many much needed things like formatting, big_integer, logging, units are not entering the library because of a search for perfection - largely unattainable as the invaluable filesystem library shows. (The Standard shows similar symptoms - there has been a desparate need for a 'typeof' since templates use started, for example, but there are no Standards, let alone implementations yet). For many problems, the Irishman's reply when asked for directions "Well I wouldn't start from here" applies: but we are committed to start from C++, multiple character sets, and a mishmash of incompatible operating systems - we have to find some one way, even if none are ideal. I agree with other would-be reviewers, that the time available and notice is too short, unless all we are to do is to finally dot is and cross the ts, and vote. Would a longer period of formally 'working on a proposal' be better? We would need to have a separate place for these 'under consideration' proposals (not files, not sandbox). So I foresee the process being: 1 Asking for interest. 2 Floating ideas and working on code. 3 Getting to a point where the submitter(s) feels that he(they) has something worth considering. 4 A 'Working on a definite proposal' period - a month perhaps. 5 Digesting input and revising, re-grouping, or abandoning, or going back to the drawing board. 5 Final formal review (a week) and vote. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com