yes.
Rémi
----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: fo...@univ-mlv.fr
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Envoyé: Lundi 4 Décembre 2017 16:20:56
> Objet: Re: compareTo and deriving
> Let's not forget that compareTo() got much easier to implement with the
> advent of the Comparator factories in Java 8:
>
> static final Comparator c
> = Comparators.comparing(Foo::int).thenComparing(Foo::bar);
>
> public int compareTo(T other) { return c.compare(this, other); }
>
>
>
> On 12/4/2017 10:12 AM, fo...@univ-mlv.fr wrote:
>> ----- Mail original -----
>>> De: "Brian Goetz" <brian.go...@oracle.com>
>>> À: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts"
>>> <amber-spec-experts@openjdk.java.net>
>>> Envoyé: Lundi 4 Décembre 2017 15:54:13
>>> Objet: Re: compareTo and deriving
>>> 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.
>> I'm trying to propose a middle ground (not too far from only support Object
>> methods) to allow to not have too much couple between the JLS and the
>> metafactory methods.
>>
>> One advantage i see to have compareTo generated is that most implementation i
>> see of the compareTo are broken either because of the primitive overflowing
>> or
>> compareTo and equals not having compatible semantics. One problem we will
>> have
>> if we let people to write compareTo is that it will be harder to get it right
>> because equals will be generated while compareTo will be written manually
>> without seeing the code of equals.
>>
>> Rémi
>>
>>>
>>> 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
