Ranges

[Tim Peierls]

On Thu, May 2, 2013 at 3:41 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> At the moment we have the {Int, Long, Double}Stream.range methods for a
> half open range of a step of 1 or a configurable step >= 0.
>
> Do we really require the configurable step methods? Perhaps they are not
> that common, if so should we remove them?
>
> Certainly one can achieve a step > 1 using map(i -> i * n), albeit less
> efficiently. Note that this will not check for overflow when the upper
> bound declared to be the maximum value.
>

Feels like unnecessary clutter in the API. Make it into a one-liner example
in the javadoc and you kill two birds with one stone: (1) Teach a person to
fish and (2) make it easy to find a fishing pole.




> The fact that we only have a half open range confuses some. Developers i
> think tend to prefer:
>   IntStream.rangeClosed('A', 'Z')
> rather than:
>   IntStream.range('A', 'Z' + 1)
> So it seems useful to add {Int, Long}Stream.rangeClosed().
>

Yes. My default expectation in general is half-open, e.g., [0, n), but in
certain contexts, like the ['A', 'Z'] case, my expectation is different.
This does *not* seem like clutter to me.



> Do we require a method for descending ranges, for example {Int,
> Long}Stream.rangeDec? what about for closed descending ranges?
>
> Again those can be achieved using map, albeit less efficiently and with
> overflow errors, and perhaps developers will make simple errors expressing
> the mapping?
>

Maybe, but like the step case, it would be clutter for no compelling
reason. Another great example for javadoc.



Should we support sizes for LongStream.range that are > Long.MAX_VALUE? for
> example:
>
>   LongStream.range(Long.MIN_VALUE, Long.MAX_VALUE)
>
> The top-level Spliterator of such a stream cannot report SIZED or SUBSIZED
> and would report an estimate of Long.MAX_VALUE.
>

Put a warning on the method that for ranges > Long.MAX_VALUE, the
implementation will split badly?

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130503/512ba39a/attachment.html