Loose end: ints(), longs()

Mike Duigou mike.duigou at oracle.com
Tue May 28 10:34:47 PDT 2013


On May 28 2013, at 09:47 , Brian Goetz wrote:

>> I'm not really keen on the ints and longs methods though. I'm already
>> used to intRange, which seems short enough, and is consistent with the
>> other names, none of which are very short.
> 
> Actually intRange was already shortened to range() when it got moved from Streams to IntStream:
> 
>  IntStream r = IntStream.range(1, 10)
> 
> The name itself is plenty short; it is the arguments that seem verbose and unnecessarily specific:
> 
>  IntStream.rangeClosed(0, Integer.MAX_VALUE)
> 
> seems more "leaky" than
> 
>  IntStream.allTheInts()
> 
> But are you saying you're fine with the verbose form?  Or simply you'd rather have a name that sounds more like "range"?
> 
>> 
>> On May 28, 2013 9:27 AM, "Brian Goetz" <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> wrote:
>> 
>>    Another loose end is a method to generate "all" ints / longs (which
>>    are sugar for ranges 0..MAX_VALUE.)

I was personally kind of confused why the range began at zero rather than MIN_VALUE. An equally simple mechanism for covering the entire range seems desirable.

If it's going to be common to want the positive non-zero range then we'll see lots of ints().skip(1).

I'm not sure ints() is sufficiently general enough. I feel like I'm just as almost as likely likely to want MIN_VALUE/MAX_VALUE, 1/MAX_VALUE, MIN_VALUE/-1, MIN_VALUE/0, etc.

>>    but some have raised concern that this might be confusing because we
>>    have an instance method on IntStream called "longs()" which widens
>>    the elements from int to long.  While this isn't fatal, it might be
>>    confusing.
>> 
>>    Perhaps it would be better to rename these conversion methods:
>> 
>>       IntStream: longs(), doubles(), boxed()
>>       LongStream: doubles(), boxed()
>>       DoubleStream: boxed()
>> 
>>    to asInts(), asLongs(), and asBoxed()?
>> 
>>    In retrospect, these seem better names anyway.  And they also
>>    eliminate the conflict above.

This does seem like an improvement.



More information about the lambda-libs-spec-observers mailing list