Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Rogier van Dalen (rogiervd_at_[hidden])
Date: 2009-02-27 06:00:05
Dear Neil,
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:
merged(rng1, rng2)
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
their interface.
Thanks,
Rogier