In Q world, we derived:
V implements I
-----------------------
box(V) <: I
which is a credible interpretation. So if we wanted to have a box-centric
interpretation, we could go back to that. But, in terms of where we want to
go, “values are objects”, and “== is same-value”, is a better place to land,
even if the road is rockier in the short run.
> On Aug 11, 2019, at 7:27 PM, Maurizio Cimadamore
> <maurizio.cimadam...@oracle.com> wrote:
>
> 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
>
