New JEP: Concise Method Bodies
Brian Goetz
brian.goetz at oracle.com
Tue Oct 9 19:48:04 UTC 2018
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>
More information about the amber-spec-experts
mailing list