Extending Collector to handle a post-transform

Remi Forax forax at univ-mlv.fr
Tue Jun 11 16:58:06 PDT 2013


On 06/12/2013 01:39 AM, Brian Goetz wrote:
> Creating a new type that only solves half the problem has negative 
> value; the user still has to puzzle about the wildcards in the 
> full-blown Collector (which show up not only when R != I, but also in 
> parameters of combinators like groupingBy), and now has to learn TWO 
> library types, one of which's sole purpose is to unsuccessfully hide 
> the other.

The idea behind SimpleCollector is not to hide Collector, but to offer a 
simple abstraction for the case where the full blown Collector is not 
needed,
like Executor/ExecutorService.
I don't think you need a wildcard if you overload Stream.collect.

Rémi

>
>
>
> On 6/11/2013 7:31 PM, Remi Forax wrote:
>> On 06/12/2013 01:24 AM, Brian Goetz wrote:
>>>> Still don't get why you can not do:
>>>> interface SimpleCollector<T, R> extends Collector<T, R, R> {
>>>>    ...
>>>> }
>>>
>>> Not all Collectors will have I=R.  Consider toStringBuilder, where
>>> I=StringBuilder and R=String.
>>
>> yes, for the ones without post-function like toList, you can use the
>> SimpleCollector, for the ones like toString you use the full blown
>> Collector.
>>
>> Rémi
>>



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