Finding the spirit of L-World
forax at univ-mlv.fr
Sat Feb 23 11:37:12 UTC 2019
----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Kevin Bourrillion" <kevinb at google.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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.rose at oracle.com> wrote:
>> On Feb 22, 2019, at 11:42 AM, Kevin Bourrillion <kevinb at 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.
More information about the valhalla-spec-experts