<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"daniel smith" <daniel.smith@oracle.com><br><b>À: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Envoyé: </b>Mardi 9 Octobre 2018 20:43:03<br><b>Objet: </b>Re: New JEP: Concise Method Bodies<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div><blockquote class=""><div class="">On Oct 9, 2018, at 12:00 PM, Remi Forax <<a href="mailto:forax@univ-mlv.fr" class="" target="_blank">forax@univ-mlv.fr</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">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.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div><div>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"...)</div></div></blockquote><div><br></div><div>ok, it makes sense if it's static final but ...<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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?)</div></div></blockquote><div><br></div><div>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 ?)<br data-mce-bogus="1"></div><div>I expect people to write a Comparator when need it and pass it as parameter.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div><div><br class=""></div><blockquote class=""><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">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.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div></div>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.</blockquote><div><br></div><div>People like inference when it works and despise it when it is not able to read their mind and report an error.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Also the 'try both' strategy doesn't works well with varargs methods (or a one with a polymorphic signature like the VarHandle API). <br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>