Hello Ivan,

Yes. It is practically the same request, only method name is different. I
do not particularly care how this method is called. So I'm not only one who
miss this method. In the next thread the name "transform" is proposed to
match method for String. jOOλ
<https://github.com/jOOQ/jOOL/blob/master/jOOL-java-8/src/main/java/org/jooq/lambda/Seq.java#L127>uses
name "transform" too.

Kotlin names this method "let", and implemented it using an extension
method on Object, at such moments I wish Java had extension methods too.

Best Regards,
Konstantin Plotnikov

On Mon, Oct 29, 2018 at 8:46 PM Ivan Gerasimov <ivan.gerasi...@oracle.com>
wrote:

> Hello Constantine!
> It seems that a request for such method was made in JDK-8210372
> <https://bugs.openjdk.java.net/browse/JDK-8210372>.
> I like the method name chain(), proposed in that request.
>
> With kind regards,
> Ivan
>
>
> On 10/26/18 2:13 AM, Constantine Plotnikov wrote:
>
> 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
>
>
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

Reply via email to