----- Mail original -----
> De: "John Rose" <john.r.r...@oracle.com>
> À: "Kevin Bourrillion" <kev...@google.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Samedi 23 Février 2019 04:02:15
> Objet: Re: Finding the spirit of L-World
> On Feb 22, 2019, at 6:57 PM, John Rose <john.r.r...@oracle.com> wrote:
>>
>> On Feb 22, 2019, at 11:42 AM, Kevin Bourrillion <kev...@google.com> wrote:
>>>
>>> I think we should make users write `equals` to test value types. If they
>>> write
>>> `==`, they are indicating a special situation where they need identity
>>> semantics, which don't make sense for value types, and that should be an
>>> error.
>>
>> This sounds like a proposal for the future, but as Brian points
>> out it is also a constraint on large amounts of generic code
>> that has already been written.
>>
>> Let's make the best of op==; it's in our past and the future
>> of comparison logic in Java is too tightly coupled with the past.
>>
>> — John
>
> P.S. Also, in exactly-typed code, the substitutability test
> will *often* be exactly what the user wants. The default
> implementation of ValObject.equals will use that test,
> and users will surely opt to inherit that rather than write
> a local equals method that does the same.
>
> (Not always, of course; there are value types and object
> types where the default equals method doesn't DTRT.
> But often, for cases like small numerics and tuples.)
>
> In that value class, requiring the user to call x.equals(y) instead
> of writing the known exact equivalent x==y feels like somebody's
> code style policy, rather than a useful discipline.
While i agree, i think it's to say that by default == on value types is a
compile error but you can opt-in to have == redirected to equals() at compiler
level.
You don't need to change acmp for that.
Rémi
