compareTo and deriving

[Brian Goetz]

As you might remember from the EG meeting, we have toyed with a notion 
of "method builders" which would be a more declarative way to declare 
template-izable methods.  The intent all along was that, once we have 
such a mechanism, records would just be a consumer of such a mechanism.

That said, such a mechanism is bigger both from a technical perspective 
and a bikeshed perspective.  90% of the current OO-ceremony-pain is in 
ctors, Object methods, and accessors.  So my preference would be to nail 
down the semantics of data classes first, and then explore whether it 
makes sense to surface a more general mechanism.


On 12/4/2017 8:34 AM, Remi Forax wrote:
> Ok,
> record/data class currently provides getters and toString/equals/hashCode, what if i want to add a compareTo.
>
> In Haskell, it's easy, one can use 'deriving', in Java, it can be written that way,
>    record Point(int x, int y) implements Comparable<Point>
>      deriving equals, hashCode, toString, compareTo;
>
> For the compiler, the method exists in the supertypes, so the signature of the method can be computed from the super types,
> after each generated method use an invokedynamic with the same meta protocol (a list of getters),
> so if by convention "equals", "hashCode", "toString", "compareTo" are the names of some bootstrap methods in a class DerivingMetaFactory,
> it can be trivial for a JDK developer to add a new bootstrap method without having to change the JLS.
>
> So my point is, that we can specify once how the compiler should generate codes for any generated methods in an extensible way.
>
> regards,
> Rémi
>
>