Gatherer API : wildcards complaint

[forax at univ-mlv.fr]

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Wednesday, January 17, 2024 9:00:32 PM
> Subject: Re: Gatherer API : wildcards complaint

> Ah, now I see what you mean! Thank you \uD83D\uDC4D

> The reason for the signature of `Gatherer.of` was to mirror as much as possible
> of `Collector.of`[1] so I would argue that if we tweak the variance of one then
> we should consider tweaking it for both.

> 1: [
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Collector.java#L264
> |
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Collector.java#L264
> ]

I agree. 
In terms of code, i suppose that we will need to add some unsafe cast because the Gatherer interface should not use wildcard (it will make the code that use the Gatherer awkward) but the factory methods should use wildcards. 
Those unsafe casts are safe because function parameter types are contravariant and return type covariant but there is no way to express than in the Java type system. 

> Cheers,
> √

Rémi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
> Sent: Wednesday, 17 January 2024 20:49
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: [External] : Re: Gatherer API : wildcards complaint

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>> <core-libs-dev at openjdk.java.net>
>> Sent: Wednesday, January 17, 2024 5:49:01 PM
>> Subject: Re: Gatherer API : wildcards complaint

>> Hi Rémi,

>> Thank you for the feedback—examples would be much appreciated!

> Here is an example with an interface and a class,

> interface Counter {
> void increment ();
> int value ();
> }

> Gatherer < String , Counter , Integer > count () {
> class CounterImpl implements Counter {
> int counter ;

> @Override
> public void increment () {
> counter ++;
> }

> @Override
> public int value () {
> return counter ;
> }
> }
> Supplier < CounterImpl > initializer = CounterImpl :: new ;
> Gatherer . Integrator < Counter , String , Gatherer . Downstream <? super
> Integer >> integrator = ( counter , _ , _ ) -> {
> counter .increment();
> return true ;
> };
> BiConsumer < Counter , Gatherer . Downstream <? super Integer >> finisher = (
> counter , downstream ) -> {
> downstream .push( counter .value());
> };
> return Gatherer . ofSequential ( initializer , integrator , finisher ); // does
> not compile :(
> }

> void main () {
> System . out .println( Stream . of ( "foo"
> ).gather(count()).findFirst().orElseThrow());
> }

> if instead of explicitly typing each functions, we directly call ofSequential,
> it works

> return Gatherer . ofSequential (
> CounterImpl :: new ,
> ( Counter counter , String _ , Gatherer . Downstream <? super Integer > _ ) -> {
> counter .increment();
> return true ;
> },
> ( Counter counter , Gatherer . Downstream <? super Integer > downstream ) -> {
> downstream .push( counter .value());
> }
> );

> because here, CounterImpl::new is inferred as Supplier<Counter>.

>> Cheers,
>> √

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
>> <forax at univ-mlv.fr>
>> Sent: Wednesday, 17 January 2024 16:55
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>> Subject: Gatherer API : wildcards complaint
>> Hello,
>> this is a minor complaint but I do not see a raison to not getting this right.

>> Currently the Gatherer API does not use the wildcard correctly, which is not
>> fully an issue because there is "enough" wildcards that if you rely on the
>> inference, it will work.

>> The problem is that when you write code, you make mistakes and usually when you
>> have a typing issue, a way to debug it is to fix the type arguments
>> de-activating the inference.
>> But because there are some missing wildcards, this debugging strategy just fail
>> flat with more typing errors.

>> I think that fixing the missing wildcards will hep users (or a least me) to have
>> a better experience when using the Gatherer API.

>> I can help and propose a PR if you want.

>> regards,
>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/81d84982/attachment-0001.htm>