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