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.
