Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Rogier van Dalen (rogiervd_at_[hidden])
Date: 2009-02-27 06:00:05
I just found that an email I wrote earlier never made it to the mailing
list. I'll re-send it, at the risk of being late at the party.
On Wed, 2009-02-25 at 16:00 +0000, Neil Groves wrote:
> boost::make_uniqued_range(rng) is equivalent to rng | uniqued
I'm sorry for having been unclear here; I meant to ask why the spelling
"make_ _range" is necessary (see Giovanni's email).
To me, RangeEx provides functions that take a range and return a range.
How is it not most natural to make these functions look like functions?
What is wrong with saying "uniqued(rng)"? Why is it vital that the name
has "make_ _range" to remind me that this returns a lazy range rather
than a range?
> > I was hoping for more lazy views on ranges, especially after reading
> > that the library allows for a "seamless funtional-style programming".
> > Shouldn't there be a generated(), randomly_shuffled(), sorted(),
> > intersected(), merged(), etc.? (I implemented lazy set operations
> > implemented and I think it's quite possible.)
> The library is intended to be extended both by myself as core needs become
> clear, and by library users. The algorithms, supported range types and
> adaptors may be implemented by users of the library without changing it.
> Many lazy adaptors are desirable. I would continue to add more as time
> permits. My focus is on producing a good foundation for this version. The
> reviews are giving me a clearer need of what people want from the library.
Fair enough. This will be fine if many reasonable algorithms can be
implemented within range_ex. However, could you state how you would
integrate lazy merge() or anything that takes two or more ranges in
operator| syntax? The function syntax would be:
I believe that the '|' syntax, however cute (I agree there!) is less
flexible and less obvious than the function syntax. Therefore, I think
the function syntax should be the primary one.
Currently merge(), transform(), and the set algorithms use output
iterators as a substitute for return values. Rephrasing them as
functions would also get rid of output iterators, which would improve
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk