Loose end: ints(), longs()

[Brian Goetz]

OK, so we have some compelling arguments against int() and longs().  I'm 
willing to drop those.

I think Paul's addition of rangeClosed to handle closed ranges 
(previously discussed) proposal is also uncontroversial?

There seems to be broad support behind renaming the existing xxxs() 
methods.  Though there now are almost as many proposals as there are EG 
members :(

as{Ints,Longs,Boxed}

as{Ints,Longs,Objs} // most consistent with map/flatMap naming

as{Ints,Longs} but keep boxed()

to{Int,Long}Stream but keep boxed()

etc...


On 5/28/2013 12:26 PM, Brian Goetz wrote:
> Another loose end is a method to generate "all" ints / longs (which are
> sugar for ranges 0..MAX_VALUE.)  These show up in pedagogical examples
> all the time:
>
>    ints().filter(i -> isPrime(i)).limit(100)
>
> The logical place for them is:
>
>    IntStream.ints()
>    LongStream.longs()
>
> 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.
>