Arrays methods

[Paul Sandoz]

On Mar 11, 2013, at 1:07 AM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> Here's a summary of stream-related methods that are currently in java.util.Arrays.  All have one-line implementations.
> 
> Object/int/long/double versions of:
>  stream(T[] array)
>  stream(T[] array, int start, int end)
>  parallelStream(T[])
>  parallelStream(T[] array, int start, int end)
>  spliterator(T[] array)
>  spliterator(T[] array, int start, int end)
> 
> Object/all primitive versions of:
>  indices(array)
> 
> The first group seems basically required but the last group seems like we can get rid of it.  (It expands to Streams.intRange(0, array.length)).
> 

> What we're missing are methods for in-place parallel mutation of arrays, such as:
> 
>  Arrays.fill(T[] array, int -> T generator)
>  Arrays.fillParallel(T[] array, int -> T generator)
> 
> One can easily simulate these with
> 
>  intRange(0, length).forEach(i -> { array[i] = generator.apply(i); })
> 

> but (a) this is harder to read than the above fill forms and (b) it is less obvious how to discover this idiom.  The indices was an attempt to make that easier but is not really any better:
> 
>  Arrays.indices(array).forEach(i -> { array[i] = generator.apply(i); })
> 
> So I think we should ditch the indices() methods but consider adding array fill methods.

Yes, indices while capturing a useful idiom seems to go only half way i.e. the presumption being if one generated indices of the array one would likely want to update the elements of the array at those indices.

FWIW we could add range methods that takes one parameter:

  range(array.length)

I think that would be better than indices.

Paul.


>  There'd be at least 9 x 2 (array types x {seq,par}) and possibly x 2 more (whole array, subarray).  Though they're all trivial.
>