Gatherers -- conditionalWindowFixed?

Remi Forax forax at univ-mlv.fr
Wed Jan 10 12:37:36 UTC 2024


> From: "Remi Forax" <forax at univ-mlv.fr>
> To: "David Alayachew" <davidalayachew at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, January 10, 2024 8:19:15 AM
> Subject: Re: Gatherers -- conditionalWindowFixed?

> Hello David,
> testing the gatherer api, I also wanted a "window" operation as the one you are
> describing.

> My use cases is a text file with some sections containing items organized like
> this

> :section1
> item1
> item2
> item3
> :section2
> item1
> item2
> ...

> For me the signature of such method, windowGroupBy??, should take a Predicate
> (is a section, so the reverse of what you are suggesting) and a function that
> take a value (for which the predicate is true) and return a Collector,
> so I can write something like

> record Section(String name, List<String> items) {}
> String input = ...
> List<Section> sections = input.lines()
> .gather(Gatherers.windowGroupBy(line -> line.startsWith(":"), name ->
> Collectors. collectingAndThen (Collectors.toList(), list -> new
> Section(name.substring(1), list))))
> .toList();

Thinking a little more, having a function that returns a Collector is a kind of an anti-pattern, it would be better to decouple the function that creates the section and the collector, so the same collector is re-used. 
So windowGroupBy?? should take a predicate, a collector and a function that takes the value (for which the predicate is true) and the result of the collector. 

< T , R , R2 > Gatherer < T , ?, R2 > windowGroupBy ( Predicate <? super T > predicate , Collector <? super T , ?, ? extends R > collector , BiFunction <? super T , ? super R , ? extends R2 > mapper ) 

Rémi 

>> From: "David Alayachew" <davidalayachew at gmail.com>
>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Wednesday, January 10, 2024 7:19:26 AM
>> Subject: Re: Gatherers -- conditionalWindowFixed?

>> And this may also be better named as a split method instead of the long
>> conditionalWindowFixed.

>> On Wed, Jan 10, 2024 at 1:17 AM David Alayachew < [
>> mailto:davidalayachew at gmail.com | davidalayachew at gmail.com ] > wrote:

>>> Oh, I made a mistake. Let me try it again.

>>> If the predicate is true, add the element to the current list (create list prior
>>> if needed). Else if the predicate is false, send the list down to the stream,
>>> then add the element to a new list (the new current list, if you will).

>>> On Wed, Jan 10, 2024 at 1:05 AM David Alayachew < [
>>> mailto:davidalayachew at gmail.com | davidalayachew at gmail.com ] > wrote:

>>>> Hello Core Libs Dev Team,

>>>> I have been reading through JEP 461 ( [ https://openjdk.org/jeps/461 |
>>>> https://openjdk.org/jeps/461 ] ) about Gatherers, and I'm really excited for
>>>> what this will enable for us.

>>>> By far, the most important functionality that this API facilitates is the
>>>> ability to create windows. Anytime I needed a window, I was basically forced to
>>>> use a for loop. Now, the 2 most common window cases are being handed to us for
>>>> free. It is very much appreciated.

>>>> Could we add one more method for a conditionalWindowFixed? We would need to pass
>>>> in some Predicate<T>. If the predicate returns true, create a list (if it does
>>>> not already exist) then add the element to it. If the predicate returns false
>>>> while the list is empty, then just move along to the next. Else if the
>>>> predicate returns false while the list is non empty, pass the list down into
>>>> the stream. So, you end up with Stream<T> -----> Stream<List<T>>.

>>>> The reason I think this is worth adding is because it facilitates a really
>>>> common use case. We may not want all windows to be the same size.

>>>> Is this something worth adding to the Gatherers API?

>>>> Thank you for your time and help!
>>>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240110/d64ce7cf/attachment-0001.htm>


More information about the core-libs-dev mailing list