Refactor of Collector interface (original) (raw)

Tim Peierls tim at peierls.net
Fri Feb 8 07:31:08 PST 2013

That's a good change. You don't need to defend it as a special case, though: I think it's actually clearer the new way.

--tim

On Fri, Feb 8, 2013 at 10:25 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

FYI: In a recent refactoring, I changed:

public interface Collector<T, R> { R makeResult(); void accumulate(R result, T value); R combine(R result, R other); } to public interface Collector<T, R> { Supplier resultSupplier(); BiConsumer<R, T> accumulator(); BinaryOperator combiner(); } Basically, this is a refactoring from typical interface to tuple-of-lambdas. What I found was that there was a lot of adaptation going on, where something would start out as a lambda, we'd wrap it with a Collector whose method invoked the lambda, then take a method reference to that wrapping method and then later wrap that with another Collector, etc. By keeping access to the functions directly, the Collectors code got simpler and less wrappy, since a lot of functions could just be passed right through without wrapping. And a lot of stupid adapter classes went away. While clearly we don't want all interfaces to evolve this way, this is one where all the many layers of manipulations are effectively function composition, and exposing the function-ness made that cleaner and more performant. So while I don't feel completely super-great about it, I think its enough of a win to keep.

More information about the lambda-libs-spec-observers mailing list