New JEP: Concise Method Bodies

[Brian Goetz]

Precisely so.  Records form the sweet spot where construction protocol, 
deconstruction protocol, equality and hashCode protocol, and 
representation are identical.  The probability that you would also want 
to use the state vector as a dictionary-order comparator is very, very 
small.

(Please, let's not tangent into redesigning records right now.) Bringing 
this back to CMB, for a record, we can add Comparable with CMB nicely:

     record Person(String firstName, String lastName, ShoeSize shoeSize)
             implements Comparable {
         private static (lazy) final Comparator<Person> COMP = 
Comparator.of(::lastName, ::firstName);

         public int compareTo(Person other) = COMP::compare;
     }

Sure, we could also write:

         public int compareTo(Person other) {
             return COMP.compare(this, other);
         }



On 10/9/2018 3:27 PM, Kevin Bourrillion wrote:
>
>     (that the reason why there is no support of Comparable on a
>     record, no ?)
>
>
> I don't think so. I think the reason is that the default behavior we'd 
> have to use is regularly enough not what the user wants. And you don't 
> want program behavior to change when fields are reordered in the 
> source file. imho, the Comparator construction methods added in 8 are 
> such an ideal way to configure comparison behavior that a language 
> feature really has no way to beat them.
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181009/309b39a2/attachment-0001.html>