Proposal Extending API for Streams (or other potentially long builder or chain calls)

[Remi Forax]

Jim Laskey ask for a similar feature on String, calling it "transform",
so i don't know if it's a good idea or not to add this API,
but at least the name should be the same.

see http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055532.html

cheers,
Rémi

----- Mail original -----
> De: "Constantine Plotnikov" <constantine.plotnikov at gmail.com>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 26 Octobre 2018 11:13:11
> Objet: Proposal Extending API for Streams (or other potentially long builder or chain calls)

> Hello All!
> 
> This email was previously filled as a feature request for JDK, I was
> forwarded here to write it as an email.
> 
> Currently, if one needs to skip some stage or provide a group of reused
> stages one to have to do the following:
> 
> Stream<T> s = collection.stream()
>     .map(a -> doIt(a, bb))
>    .filter(a -> !a.list().isEmpty());
> s = useSecuriytFilter(s, session)
> return s.collect(Collector.toList());
> 
> Or like:
> 
> return useSecuriytFilter(collection.stream()
>     .map(a -> doIt(a, bb))
>    .filter(a -> !a.list().isEmpty())
>    , session);
>    .collect(Collector.toList());
> 
> In both cases, readability is of code is not high, as fluent sequence of
> actions is interrupted.
> 
> It is suggested to add "process" method to stream like the following
> signature:
> 
> default <R> R process(Function<Stream<T>, R> body) {
>   return body.apply(this);
> }
> 
> Then custom processing could be applied like the following:
> 
> return collection.stream()
>    .map(a -> doIt(a, bb))
>    .filter(a -> !a.list().isEmpty()
>    .process( s -> useSecuriytFilter(s, session))
>    .collect(Collector.toList());
> 
> While semantics is the same, the code structure looks much better. Note
> this proposed change is not about less typing, but about making local
> processing looking more local, rather than affecting entire processing
> pipeline visually.
> 
> The detailed description for motivation is here:
> 
> https://dzone.com/articles/making-java-fluent-api-more-flexible
> 
> Some other libraries with processing chain usage pattern like date-time
> classes in java.util.time could benefit from this too as common blocks of
> date arithmetic could be reused in more clean way.
> 
> A possibly better alternative to this functionality is the support for
> extension methods like in Groovy, Kotlin, or C#, so users will be able to
> create such methods when needed themselves, not waiting for library
> designers. I think extension methods are good innovation enablers, as they
> allow users of JDK or some library  to try new API ideas in the practice
> first, and than to discuss their experience with component authors.
> 
> Best Regards,
> Konstantin Plotnikov