Collectors update
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<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>
>>
More information about the lambda-libs-spec-experts
mailing list