On Feb 20, 2019, at 5:48 PM, Brian Goetz <brian.go...@oracle.com> wrote:
>
>
>>
>> It doesn't match my experience, currently people have no expectation of what
>> == means on a value type, if you explain that a value type has no identity,
>> that == doesn't work on a value type, most people are ok with that.
>
> I think this is fantasy.
>
> Value types are OBJECTS. People think they know what == means on an Object,
> and for most users, the word "identity" does not come to mind. Further,
> we've told people that "values have only state, no identity -- if two values
> have the same state, they are the same." For such values not to be == will be
> astonishing.
I think I have to agree with Brian here. The key idea here is
"will be astonishing", emphasis on "will". I can believe that
at first introduction to non-reflective equality people might
shrug, but actually living with it in the long term is surely
a different matter. If my car makes a funny noise in the
used car lot, I might shrug it off and buy the car, but if it
makes it every time I drive to work I will start to pay
attention, with some buyer's regret. I am afraid we will
regret non-reflexive op==. Imagine a world where
many numbers act like NaN (n!=n). That's kind of what
we would be signing up for.
> Consider:
>
> value class UnsignedInt {
> public static UnsignedInt ZERO = ...
>
> private int i;
>
> public static add(UnsignedInt a, UnsignedInt b) { ... }
> }
>
> UnsignedInt x = ...
> if (x != UnsignedInt.ZERO) { ... }
>
> People will never, ever, ever get used to the idea that test is always false.
> Its a fantasy to think otherwise. And the WHOLE POINT of L-World is to
> allow people to not sweat the small details between values and refs. This is
> asking them to be acutely aware all the time.
To put it another way, in terms of buyer's remorse: If people
shrug off op== anomalies on first glance, it can only get worse
in the future, as they hit bugs in their code coming from those
anomalies.
This last example reminds me of another mitigating
circumstance with structural acmp: Just as many comparisons
of references today are against null, and that's cheap
no matter what odd stuff is going on under the JVM,
many value comparisons will be against initial or
default values. In those cases, one of the two compared
values will have little or no deep structure, so the
comparison will be O(1). The O(N) comparisons will
show up only when pairs of deeply structured values
are being compared. If those are places where
Object.equals (part of LIFE) is also in play, then
we can neglect the O(N) comparison as a constant
multiplier on Object.equals, or even merge it into
Object.equals as I suggested previously.
