Re: [boost] Formal Review: Boost.RangeEx

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