groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Comparator argument type inference
Date Mon, 12 Oct 2015 12:51:42 GMT
On 12.10.2015 07:51, Peter Ledbrook wrote:
> Hi,
>
> So, I had a difference of opinion with Marcin Erdmann on camera about
> closure parameter type inference with functional interfaces. I said it
> didn't work in my experience. Thankfully, Marcin worked out why my example:
>
>      import groovy.transform.TypeChecked
>
>      @TypeChecked
>      def someMethod() {
>          List<Integer> numbers = [1, 4, 56, 35]
>          Collections.sort(numbers, { a, b -> a.abs() <=> b.abs() })
>      }
>
> doesn't compile. The problem is that Comparator, despite having the
> @FunctionalInterface annotation, defines two methods: compare() and
> equals(). Interestingly, {...} as Comparator works fine though.

And I thought we had even a test case for this... Comparator is 
effectively a functional interface, because Object#equals will always 
provide an implementation. Oh... this is in type checked! Ok... well 
basically same story. Since it does not work, this is a bug in the 
implementation. And now I remember that I added this ability for 
Comparator later on... meaning that I most probably forgot to add it to 
the type checker as well.

> So, does it make sense to add a special case for Comparator so that type
> inference works? Or perhaps a special case for any interface that only
> has one method that's not defined on Object as well?

The later, yes.  So basically hashcode(), toString() and equals(Object) 
need special treatment

bye blackdrag


Mime
View raw message