Ranges

[Paul Sandoz]

On May 3, 2013, at 2:56 PM, Tim Peierls <tim at peierls.net> wrote:

> 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.
> 

Yes, i don't know how common overflow cases might be, but in general we can provide simple examples in JavaDoc for the very common cases where map can be used.

Unless there are no further objections i propose to remove the configurable step on int/long ranges.

The same argument can be made for removing DoubleStream.range since one can use LongStream and map, but i am hesitant to go that far since we might be able to do something useful handling many edge cases associated with floating point numbers.


> 
> 
> 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?
> 

It will split OK, since it can be divided into the negative and non-negative sub-ranges [Long.MIN_VALUE, 0) and [0, Long.MAX_VALUE). But i agree a warning on the behaviour of the estimated size is useful.

FWIW it is edge cases like this that can complicate the implementation at the expense of the most common cases.

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