Collectors update (original) (raw)

Remi Forax forax at univ-mlv.fr
Tue Feb 5 13:38:13 PST 2013

On 02/05/2013 09:54 PM, Brian Goetz wrote:

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.

Why using Map is a "real data structure" ? I think I prefer to have a real type like Partition (as Don said).

Rémi

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 Collector<T, Collection[]> partitioningBy(Predicate predicate, IntFunction<Collection[]> 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>

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