Generators

[Brian Goetz]

Related to generators is array pre-filling.

Originally I'd though we might want

   Arrays.fill(arr, Supplier<T>)

but that gets doubled with {fill,parallelFill} versions.  A possibly 
more general approach is:

   IntStream Arrays.indexes(array)

which would generate an intRange(0, array.length).  Then filling becomes

   Arrays.indexes(array).forEach(i -> array[i] = ...)
or in parallel
   Arrays.indexes(array).parallel().forEach(i -> array[i] = ...)

This also subsumes other use cases like replaceAll, conditional replace, 
etc, with less library code.

On 1/3/2013 2:49 PM, Brian Goetz wrote:
> I'm looking over our generators.  Currently we have:
>
>    repeat(T)
>    repeat(n, T)
>    repeatedly(Supplier<T>)
>    repeatedly(n, Supplier<T>)
>    iterate(T, UnaryOperator<T>)
>    cycle(Iterable)
>
> I'd like to pare this down a lot.  Paul and I have been discussing
> techniques for making limit() more efficient, at which point the first
> four can collapse to
>
>    generate(Supplier<T>)
>
> since you can simulate repeat(T) with generate(() -> T) and the limited
> versions with generate().limit().
>
> That leaves us with
>
>    iterate(T, UnaryOperator<T>)
>    cycle(Iterable)
>
> and I'm thinking cycle doesn't pull its weight either.  If we took that
> out, we'd be down to the pleasantly small set of:
>
>    generate(Supplier<T>)
>    iterate(T, UnaryOperator<T>)
>
> For integer generators, we have
>
>    range(from, to)
>
> and I think we should add
>
>    ints() -> sugar for range(0, MAX_INT)
>
> (Or should ints() be truly infinite, wrapping around?)
>