Is V? what we need ?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 1 Mai 2019 15:13:06
> Objet: Re: Is V? what we need ?

> 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.

More boxes is a temporary answer until we have fully reified generics because at that point we have generics over value types.
Here we want to introduce boxes not because value type are not objects but because value types are not nullable objects but T is a nullable object.

So it's a different kind of box, for a different reason but that it should work like a box because our users are already familiar with the box model.


> 
> 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…..

until you think that N? is a temporary evil, in LW1000, when generics are reified using N? with a generics will be a corner case, so there is no reason to make N? powerful to the point they appear in method signature, because at that point it's too late.

And yes, it's weird to actually promote for a less powerful semantics for N? but i think it's the right move.

Rémi

> 
> 
> 
>> On May 1, 2019, at 9:07 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>> 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