Hmm, it's difficult for me to perceive what these benefits are from looking
at the change to
Collectors.java<http://hg.openjdk.java.net/lambda/lambda/jdk/diff/221c5b4f706c/src/share/classes/java/util/stream/Collectors.java>,
and the file did get 70 lines longer as a result of the change fwiw, and
seems to rely more on private abstract base classes that other Collector
implementors won't have.
(How do you get to side-by-side diff in this thing? I feel quite blind
without it and am thus stuck in "I don't get it" mode.)
On Fri, Feb 8, 2013 at 8:22 AM, Kevin Bourrillion <kevinb at google.com> wrote:
> My subjective sense of good Java API design very strongly prefers the
> "before" picture here, which I see as a lot more "Java-like", so I'm taking
> a closer look.
>> I assume that the trade-offs we're weighing here are purely to do with
> what it's like to be a Collector implementor, correct?
>>> On Fri, Feb 8, 2013 at 7: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<R> resultSupplier();
>> BiConsumer<R, T> accumulator();
>> BinaryOperator<R> 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.
>>>>>>> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com>
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130208/178ab800/attachment-0001.html