Arrays methods

[Joe Bowbeer]

indices(array) could be useful for sparse arrays, if that is in the cards.

I think that Streams.intRange(0, array.length) is a large enough expression
that indices has some utility. And I think the relationship between
indices() and fill() is overstated.

OTOH, I have not yet used indices, so I cannot defend it very strongly.



On Sun, Mar 10, 2013 at 5:07 PM, 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.  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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130310/efa2be14/attachment.html