Collectors update redux

[Kevin Bourrillion]

Okay, I got a presentation over with that was stressing me out and returned
to this. :-)  I think I've spoken too broadly and been unfair to a degree.
 I'll start a new thread soon with a more constructive approach.


On Thu, Feb 7, 2013 at 12:25 PM, Kevin Bourrillion <kevinb at google.com>wrote:

> On Thu, Feb 7, 2013 at 11:34 AM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>  I think there is *way* too much stuff in there, and I don't have enough
>>> time to even review it all before it gets set in stone.
>>>
>>
>> "Too much stuff here" is kind of vague.
>>
>> Is the concern that some of the operations (e.g., partition) are just too
>> niche to carry their weight?  Or not fully baked as concepts?
>>
>> Or are some so obvious that we just expect people to write it themselves
>> if they need it?
>>
>> Is the concern that there are too many forms of each operation, and that
>> the user will be bewildered by the variety?
>>
>> Is it the complex interaction of {concurrent, ordered}?
>>
>> Can you point to a few examples of methods you would eliminate?  Maybe we
>> can induct to a pattern from there.
>>
>
> So... This illustrates the problem I'm talking about.
>
> You're implying "we need a specific argument to justify leaving X out" and
> the further implication is that if you feel you can refute that argument,
> it stays in. That's the opposite of how it works in my project ... and we
> actually get to remove our mistakes later!
>
> Did I miss all the discussions where each of the 40 (!) static Collectors
> provided was carefully considered on its merits?
>
> --
> 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/20130207/9e525154/attachment.html