Collectors update

[Brian Goetz]

That's silly.  We didn't say anything about "nothing should return a 
function."

Kevin is completely right that collect() is a data-oriented operation 
and should return a real data structure.

Consumer.chain() is a higher-order function; functions in, functions out 
-- no data involved.

On 2/5/2013 3:46 PM, Remi Forax wrote:
> On 02/05/2013 09:22 PM, Brian Goetz wrote:
>> I concur with Kevin.
>
> We should remove Consumer.chain() in that case.
>
> Rémi
>
>>
>> On 2/5/2013 3:20 PM, Kevin Bourrillion wrote:
>>> On Tue, Feb 5, 2013 at 11:11 AM, Remi Forax <forax at univ-mlv.fr
>>> <mailto:forax at univ-mlv.fr>> wrote:
>>>
>>>                 4.  Rejigger Partition to return an array again, with an
>>>                 explicit
>>>                 lambda (which will likely be an array ctor ref) to make
>>>                 the array.
>>>                 Eliminated the silly Partition class.
>>>
>>>
>>>             Please don't do that, it's pure evil.
>>>                 public static<T> Collector<T, Collection<T>[]>
>>>             partitioningBy(Predicate<T> predicate,
>>>             IntFunction<Collection<T>[]>
>>>             arraySupplier) {
>>>
>>>
>>>         I've refactored this to make the partition collectors return
>>>         Map<Boolean, X>.
>>>
>>>
>>>     I think returning a boolean -> T (or Boolean -> T) is better because
>>>     it's conceptually more lightweight than a Map.
>>>     I expect to see more function instead of a Map returned as result of
>>>     a method.
>>>
>>>
>>> I'd have to disagree; I expect function objects to be little things I
>>> pass /in/, but I think it's more intuitive to expect a proper data
>>> structure back out.
>>>
>>>
>>> --
>>> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
>>> <mailto:kevinb at google.com>
>