From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-24 09:30:52
On Fri, Oct 24, 2003 at 09:38:09AM +0100, Paul A. Bristow wrote:
> These seems acceptable to me, but I would still like to see a large number of
> overcommented examples/tests of how they would work in practice. (The examples
> should include some that don't work). These would be a most valuable part of the
> documentation (a vital part of selling the code to the majority of users who are
> novices). And it might reveal some disadvantages that are not yet apparent.
There is never enoguh examples:) This point is clear, but it takes a time to figure
out all possible useful examples. I'm adding new examples regulary, and it would
be very helpful if others can contribute as well.
> Overall I feel these string handling things are essential and this library will
> be acceptable.
> A couple of very minor observations:
> 1 I don't think that abbreviating to 'algo' is in keeping with Boost preference
> for clarity over curtness.
Well, there is also sequence_algo and container_algo library being developed in
the sandbox. It is highly probable that in the future, there will be one
algorithms library shielding all of these.
> 2 The suffix should be _copy and _copyto.
Why? Could you plese provide rationale for this.
> PS I feel this long dialog may be showing a weakness in the review process. I
> can (from experience) understand authors' reluctance to put a lot of work into
> the documentation (or redoing code) unless one can be sure that the code is
> going to be accepted. Do we need to accept a proposal in principle, then have a
> revision period, and then finally review and accept as 'official' release
> version (1st version anyway)?
This is a good idea, but I'm not sure if it won't bring too much burden to boost
reviewers, because it would require their focus for a much longer perior of time.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk