Refactor of Collector interface

[Tim Peierls]

OK, throwing away the taste argument. And I don't feel completely
super-great about anything, so I'm right there.

On Fri, Feb 8, 2013 at 12:30 PM, Kevin Bourrillion <kevinb at google.com>wrote:

> On Fri, Feb 8, 2013 at 9:13 AM, Tim Peierls <tim at peierls.net> 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.
>>
>>
>> The before picture is certainly more pre-lambda-Java-like, but I don't
>> think it's fair to knock something meant to fit well with a new language
>> feature by those rules.
>>
>
> I think I'm only really saying the same thing Brian is when he says "While
> clearly we don't want all interfaces to evolve this way..." and "while I
> don't feel completely super-great about it....", etc.
>
> I'd prefer to not rely on the taste argument if we can treat the benefits
> concretely.
>
>
>
>>
>> I thought the return types of the after picture conveyed more clearly the
>> idea of "I'm going to need a way to supply result objects, and way to
>> accumulate elements into result objects, and a way to combine result
>> objects."  And seeing those interface types as return types reinforced my
>> understanding of those types.
>>
>>
>> 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?
>>>
>>
>> Well, since I persist in preferring the after picture -- maybe the
>> impending blizzard has addled my senses -- I'd say the benefit to Collector
>> implementers is secondary.
>>
>> --tim
>>
>
>
>
> --
> 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/cf4c33f1/attachment.html