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
