Refactor of Collector interface (original) (raw)

Tim Peierls tim at peierls.net
Fri Feb 8 10:41:22 PST 2013

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

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