Converting Consumers to Functions

前端 未结 2 1337
暖寄归人
暖寄归人 2020-12-16 12:58

Many lambdas for the Function interface take the form

t -> {
    // do something to t
    return t;
}

I do this so often th

相关标签:
2条回答
  • 2020-12-16 13:30

    Apache commons collections 4.x has what you're looking for, I think. Its equivalents for Function and Consumer are Transformer and Closure, respectively, and it provides a way to compose them using ClosureTransformer

    It is trivial to convert between equivalent functional types by invoking the SAM of one and assigning it to the other. Putting it all together, you can end up with a Java 8 Function in this manner:

    Consumer<String> c = System.out::println;
    Function<String,String> f = ClosureTransformer.closureTransformer(c::accept)::transform;
    

    c::accept converts the Java 8 Consumer to an equivalent Apache Commons 4 Closure, and the final ::transform converts the Apache Commons 4 Transformer to an equivalent Java 8 Function.

    0 讨论(0)
  • 2020-12-16 13:50

    There are many potentially useful methods that could be added to the Function, Consumer and Supplier interfaces. You give a good example (converting a Consumer to a Function) but there are many other potential conversions or utilities that could be added. For example, using a Function as Consumer (by ignoring the return value) or as a Supplier (by providing an input value). Or converting a BiFunction to a Function by supplying either value. All of these can, of course, be done manually in code or provided via utility functions as you've shown but it would arguably be valuable to have standardised mechanisms in the API, as exist in many other languages.

    It is speculation on my part, but I would guess this reflects the language designers' desire to leave the API as clean as possible. However I'm intrigued by the contrast (as an example) to the very rich set of Comparator utilities provided by the language to reverse orders, compare by several criteria, deal with null values etc. These also could easily have been left to the user but have been supplied by the API. I'd be interested to hear from one of the language designers why the approaches to these interfaces seems so inconsistent.

    0 讨论(0)
提交回复
热议问题