Yes, I think we'd design things such that we'd have a consistent streaming
approach for all things where it made sense, e.g. object collections, XML,
SQL, JSON etc. We can debate specific method names down the track.
Cheers, Paul.
On Fri, May 24, 2019 at 2:49 PM Simon Sadedin <ssade...@gmail.com> wrote:
> On Fri, May 24, 2019 at 10:28 AM Paul King <pa...@asert.com.au> wrote:
>
>
>> Also, if you have anything you'd particularly like to see in Groovy 4,
>> please discuss. I'll have a slide on potential things in Groovy 4 in my
>> gr8conf talk next week. I'd like to include as many sensible ideas as
>> possible to make use of the opportunity to garner feedback on what our
>> users are looking for.
>>
>> Some of the things currently on my list:
>> * improved module support (including split package final steps)
>> * further invoke dynamic improvements (including deferred merge to indy
>> only)
>> * stream-based replacements for XmlSlurper et al
>> * groovydoc rework (assuming we manage to finish porting the current
>> groovydoc to 3)
>> * improved built-in type checking extensions (@NonNull et al)
>>
>
> I am wondering if there would be receptiveness to adding streaming based
> versions of Groovy's standard collection methods. ie: currently
>
> foo.collect { it * 2 }.grep { it > 10 }.take(3)
>
> fully evaluates the collect, then fully evaluates the grep, finally only
> to take 3 results. Java streams now solves this as do other languages
> (python generators, etc), but in Groovy you have to abandon the "groovy"
> methods and use Java streams (which works somewhat).
>
> I could imagine this could be done just by adding 's' to all the methods:
>
> foo.collects { it * 2 }.greps { it > 10 }.takes(3)
>
> Of course people might find that a bit ugly and there could be different
> syntaxes or solutions .... but it would be really nice to have this
> "natively" in Groovy!
>
> Cheers,
>
> Simon
>
>
>
>
>
>
