EnumeratedStream

[-]

Hi Oleksandr,
I fear that enumeration might not be applicable to all streams, especially
parallel ones. If we have a parallel stream, we might not always process
all elements in order, and even index generation can be unreliable. In
addition, stream merging will become a headache. I think Gatherers.scan(()
-> new Indexed<>(0, dummy), (indexed, value) -> new
Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
which should serve your purpose.

And for expanded operations for enumerated streams, there are similar
features for primitive streams already, where they have extra methods like
summaryStatistics() compared to object streams. We most likely will have
Gatherers that explicitly work on Stream<Indexed<V>> to support
type-specific operations, partly due to Java's type limits and that Stream
hierarchy is effectively closed.

Best,
Chen Liang

On Sat, Apr 20, 2024 at 4:07 PM ІП-24 Олександр Ротань <
rotan.olexandr at gmail.com> wrote:

> My proposal regarding findIndex brought up a topic that, as I see, has
> been brought up here multiple times.
>
> My idea is to extend the existing stream interface in the new
> EnumeratedStream interface. Such an approach has a number of advantages.
>
> 1. Some methods will be able to explicitly specify that they require an
> enumerated stream.
>
> 2. This would allow us to use an enumerated stream just as the default
> value stream, if the index is redundant at a certain processing step.
>
> 3. This could help introduce a more user-friendly interface: instead of
> passing pairs of index and value, they could be passed as separate
> variables, which will make code more concise.
>
> Consider following example:
> List.of(1, 2, 3).stream()
>                 .enumerated()
>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>
> looks much better than
> List.of(1, 2, 3).stream()
>                 .enumerated()
>                 .map(pair -> pair.idx % 2 == 0 ? pair.value : -pair.value);
>
> However, I see some caveats with this approach, which relate to parallel
> streams:
> when a stream is backed by a collection, you might expect assigned indexes
> to represent order of iteration through collection, especially when talking
> about sequential collections. Assigning indexes in such streams could be a
> difficult task in a parallel environment. It should either assign index to
> a stream elements at the moment when stream becomes parallelized, which is
> also impossible if already parallelized stream is being enumerated, and
> also wont work for infinite streams, or make enumerated stream at least
> partially sequential by passing elements to processing in order they were
> passed to stream at the first place, which is also hard or maybe even
> impossible to achieve.
>
> Also, side note: methods that already accept 2 parameters might become
> kinda verbose, like reduce that will have to accept for params (idx1, val1,
> idx2, val2), but i think that is not a big deal
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/13162438/attachment-0001.htm>