Comparator combinators

[Henry Jen]

I prefer leave it as is and force use of explicit lambda or non-ambiguous method reference.

For one reason John had mentioned before, when one intend to

comparingInt(x -> x.size()) and wrote comparing(x -> x.size()) instead, boxing kicks in and the code still works. Forcing to write comparing((IntFunction<T>) x -> x.size()) is not too bad IMHO.

My feeling is that most commonly use cases are covered in test/java/util/Comparator/BasicTest.java, and those compiles fine without extra casting.

Cheers,
Henry


On Aug 14, 2013, at 12:49 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> This may well be our last API loose end...
> 
> We currently have a pile of Comparator combinators, all currently called comparing() or thenComparing().  Regardless of whether we choose to go forward with the simplified overloading plan, these overloads have a problem: for implicit lambdas, we can't distinguish between
> 
>  comparing(T->U)
> and
>  comparing(T->int)
> 
> because we don't type-check the body of the lambda until we do overload selection, and don't do overload selection based on whether there are type errors in the body (this was roundly rejected as being too brittle).  So for lambdas like:
> 
>  comparing(x -> x.size())
> 
> we've got a circularity -- even under the older, more complex scheme.
> 
> We'd thought perhaps that, if we adopted the heuristic that we can eagerly give a type to method reference that refers to a non-overloaded method (e.g., Person::getAge), then cases like
> 
>  comparing(Person::getAge)
> 
> can be handled, and this might take some of the pressure off the problem.
> 
> For lambdas (with either approach) you can always get what you want with an explicit lambda:
> 
>  comparing((Person p) -> p.getAge())
> 
> since this can be type-checked early.
> 
> So the question is, is this good enough, even though it falls afoul of the overloading guidelines for implicit lambdas?  Or, should we mangle the names of the methods?
> 
> This question comes down to whether we think its better to force everyone to explicitly pick a method, but then supporting implicit lambdas:
> 
>  comparingInt(x -> x.size())
> 
> or forcing users to use non-ambigous method refs or explicit lambdas:
> 
>  comparing(Person::getAge)
> or
>  comparing((Person p) -> p.getAge())
> 
> Which disambiguation approach is worse?
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130815/b368ee03/attachment-0001.html