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

Reply via email to