Agree on the analysis - in a world where values ARE objects, == needs to
mean the right thing. Any other answer will be seen as trickery.
On 09/08/2019 16:46, Brian Goetz wrote:
The alternate route to preserving a narrower definition of == is to say that_at
the language level_, values are not subtypes of Object. Then, we can credibly
say that the eclair companion type is the box, and there is a boxing conversion
between V and I (putting the cream in the eclair is like putting it in a box.)
This may seem like a huge step backwards, but it actually is a consistent
world, and in this world, boxing is a super-lightweight operation. The main
concern here is that when a user assigns a value to an object/interface type,
and then invokes Object.getClass(), they will see the value class — which
perhaps we can present as “the runtime box is so light that you can’t even see
it.”
We have discussed this at the EG meeting in Santa Clara two weeks ago -
IIRC the conclusion there was that, since values can implement
interfaces, it would be odd for values not to subtype same interfaces;
and Object is really just another kind of interface.
FWIW, I too sense that subtyping is 'boxing' us in (and have been in
favor of finding ways to cut that particular knot) - but I realize the
above argument is also very strong.
Maurizio
