I agree with Brian that most of the 'conversion-like' nature we see in V
to V? is likely associated with Q-thinking, after having been a victim
of it myself in a private conversation :-)
However, I think my more general point remains - the fact that the VM
has the flexibility to treat V and V? as, fundamentally, the same thing
shouldn't necessarily drive the conclusion that, _at the language level_
there should be a subtyping relationship between V and V?.
From a pedagogical perspective, whether we like it or not, users are
immediately going to think in terms of box/unbox, so I think it'd be
surprising if the new inline classes and their projections had rules
radically different from those which apply to the int/Integer case.
Maurizio
On 01/05/2019 14:13, Brian Goetz wrote:
But, this is Q-world thinking. In Q-world, values are like primitives, and we
therefore need boxes to interoperate with objects. In L-world, values *ARE*
Object. The difference is huge, and it takes some time to internalize just how
different they are. We’re all in varying degrees of realizing the implications.
Boxes are not a good thing; they were a necessarily evil that arises from the
fact that primitives are not objects. But they create many problems of their
own. I don’t see how “more boxes” is the answer here.
The main argument in favor of “more boxes” is that “users are already familiar
with the model.” For a while, we thought that was a good thing, but this is
mostly Stockholm Syndrome…..
On May 1, 2019, at 9:07 AM, Maurizio Cimadamore
<[email protected]> wrote:
I agree, in principle - and I have raised similar points in the past, that is:
V ~= int
V? ~= Integer
And have NO subtyping relationship between them; this puts the language on a
solid footing, where we reuse existing conversion mechanism to sequence
overload resolution and all that.
I think what pushed us down this path was perhaps the perceived usability fall
back: e.g. we can no longer pass a V where a V? is expected. But that's not
really the case, as you still have assignment conversions between the two,
which means it would work on assignment context and method calls (albeit with
lower priority w.r.t true subtypes, which is what we want anyway).
Maurizio
On 01/05/2019 13:57, Remi Forax wrote:
Brian ask me to make it its own thread.
so is V? what we need, because i believe we have been a little over our own
head on this and loose the sight of what we need for V?.
we need V?
- to represent the L variation of a Q type.
- to interact with generics that are not reified.
V? does that but does far more, V? is a super type of V which is dangerous,
because people will use it as parameter of function instead of V because it's a
super type and works with null.
Here we are back to a world were every value types may be null.
I believe that the issue is that V? should work as a box and currently V? is to
powerful/useful as a box so people will start to use it as a true type.
- V? should not be a supertype of V
- you should not be able to call methods or fields on V? (constructor are still
allowed), again it should be a box, so the automatic conversions from/to V/V?
are fine, but not more.
the moto for V? should be works like an Integer (not more).
Rémi
