Extending Collector to handle a post-transform

[Remi Forax]

On 06/11/2013 09:02 PM, Brian Goetz wrote:
>
>
> On 6/11/2013 1:44 PM, Tim Peierls wrote:
>> On Tue, Jun 11, 2013 at 1:26 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> wrote:
>>
>>         Yes, it's not yet "all gain, no pain".  Where I am now, the
>>         existence of an internal type still appears; Collector takes
>>         type arguments <T, I, R> (input, intermediate, result), but all
>>         the occurrences of Collector in the API specify ? as the second
>>         parameter:
>>
>>
>>          public static Collector<String, ?, String> toStringBuilder()
>>
>>
>> That's not as bad as I feared, but given the importance of Collector to
>> the whole Stream framework, I'm still worried about scaring people away
>> with mysterious type parameters. Could Collector<T, R> extend
>> BaseCollector<T, X, R>? Implementers of the latter care about X, clients
>> of the former don't.
>
> I haven't been able to make this work nicely.  You can move the ugly 
> somewhere else, but its not clear whether it is a win.
>
> For example, you could not do:
>
>   interface BaseCollector<T,I,R> {
>       Supplier<I> resultSupplier();
>       BiFunction<I,T,I> accumulator();
>       ...
>   }
>
>   interface Collector<T,R> extends BaseCollector<T,?,R> { }
>
> (compile-time error).
>
> You could do:
>
>   interface Collector<T,R> extends BaseCollector<T,Object,R> { }
>
> which is arguably uglier, and now we're getting into the "poor man's 
> typedef antipattern", since the interface Collector does nothing 
> except to obfuscate the type arguments of BaseCollector.

if there is no post transformation, It should be R.
    interface Collector<T,R> extends BaseCollector<T,R,R> { }

no ?

Rémi