New JEP: Concise Method Bodies

[forax at univ-mlv.fr]

> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 9 Octobre 2018 20:43:03
> Objet: Re: New JEP: Concise Method Bodies

>> On Oct 9, 2018, at 12:00 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>> Aside, from the semantics point of view, this is a very bad example,
>> implementing Comparable means you have a natural order for the class and taking
>> a Comparator as parameter means there is no natural order.

> Note that 'comp' has an initializer. I'm not "taking a Comparator as a
> parameter"—I'm building a comparator and cacheing it. (Probably should be
> "static final"...)

ok, it makes sense if it's static final but ... 

> We have a rich API for building Comparators. I would expect most non-legacy
> implementations of Comparable to implement their 'compareTo' method by
> delegating to a Comparator. And you don't want to build the Comparator each
> time the 'compareTo' method gets called, so you'll probably stash it in a
> field.

> I'm curious about what you'd expect someone to put inside their 'compareTo'
> method body, if not an invocation of Comparator.compare. (Of course they can
> roll their own int-fiddling logic, but why when the Comparator API is sitting
> right there?)

I don't expect a lot of people to write their own compareTo because not a lot of classes have a natural order (that the reason why there is no support of Comparable on a record, no ?) 
I expect people to write a Comparator when need it and pass it as parameter. 

>> The main issue with the 'try both' strategy is that we already support two kinds
>> of method ref, static method and instance method, so if the compiler also tests
>> the two kind of strategy, it means that we have a 2x2 matrix of possible
>> signatures to match, this introduced too many possibilities for a feature that
>> is supposed to be readable for everyone.

> I'm sympathetic to the argument that more complexity is bad. On the other hand,
> this is an inference problem, and people tend to be pretty happy with complex
> inference rules, if those rules produce a result that is what they intuitively
> expect, and as long as reasonable ambiguities are reported as errors rather
> than arbitrarily resolved.
People like inference when it works and despise it when it is not able to read their mind and report an error. 

Also the 'try both' strategy doesn't works well with varargs methods (or a one with a polymorphic signature like the VarHandle API). 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181009/e75f7ebf/attachment.html>