JEP 473: Stream Gatherers (Second Preview)

[Ernie Rael]

> Filter isn't many-to-... At all, at no point it collapses a 
> subsequence of elements, it only works on one element at a time 
I was conflating the behavior of a specific intermediate operation with 
a black box view of an operation. Looking at an operation as a black box 
is useless (maybe mildly interesting at most). The description of filter 
as "one-to-many" threw me off balance (this is the first time I read the 
gatherer spec in detail, and I've only looked at streams on an as need 
basis, it took this long having brief exposures till I felt ready); but 
as was said, the precise description of filter is "1-to-0..1".

I'm still curious about the idea of an "empty" input?. Seems like "many" 
on the left side is never "0", in particular something like: 
"1..N-to-SomeRange"

Thanks to all,
-ernie

PS. Looking at flatMap (and mapMulti) was a good exercise.

On 24/04/07 11:24 AM, Holo The Sage Wolf wrote:
> Think about `flatMap` (which filter is a special case of), this is 
> one-to-many function that can also return 1 or 0 elements for each 
> input. So it makes sense to include 0 as "many".
>
> Filter isn't many-to-... At all, at no point it collapses a 
> subsequence of elements, it only works on one element at a time
>
> On Sun, 7 Apr 2024, 19:31 Ernie Rael, <errael at raelity.com> wrote:
>
>     On 24/04/07 9:11 AM, Viktor Klang wrote:
>>     Hi Ernie,
>>
>>     "Many" in this case refers to "N", which is "0 ... N",
>     OK, I was wondering about "many" including "0".
>>     so I'd say while it is techincally correct as-is, perhaps more
>>     precise would be to say "1-to-0..1" gatherer, since for every
>>     element in, there is 0 or 1 element out.
>     I see.
>>
>>     Many-to-one would be 0..N -> 1, which means that an empty input
>>     would
>     "could" not "would"?
>>     yield a single output.
>
>     Out of curiosity, is either correct technically?
>
>
>     Other than at  initialization or finish, is it possible to have an
>     "empty" input?
>
>
>     -ernie
>
>>
>>     Cheers,
>>     √
>>
>>     *
>>     *
>>     *Viktor Klang*
>>     Software Architect, Java Platform Group
>>     Oracle
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org> on behalf of Ernie Rael
>>     <errael at raelity.com> <mailto:errael at raelity.com>
>>     *Sent:* Sunday, 7 April 2024 18:06
>>     *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>>     <mailto:core-libs-dev at openjdk.org>
>>     *Subject:* JEP 473: Stream Gatherers (Second Preview)
>>
>>     This is about what might be a minor doc issue.
>>
>>     In https://openjdk.org/jeps/473 it says
>>
>>>     As another example, |Stream::filter| takes a predicate that
>>>     determines whether an input element should be passed downstream;
>>>     this is simply a stateless one-to-many gatherer.
>>     Shouldn't this be "many-to-one"?
>>
>>     -ernie
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240408/a217d863/attachment-0001.htm>