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.plotni...@gmail.com> > À: "core-libs-dev" <core-libs-dev@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
