Is V? what we need ?

[Remi Forax]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Doug Lea" <dl at cs.oswego.edu>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 1 Mai 2019 16:39:59
> Objet: Re: Is V? what we need ?

> This is the point I’ve been failing to get across to Remi as well.  Suppose you
> have a big value, and you want a sparse ArrayList of that value?  You need a
> way to say “Arraylist of BigValue, but not flattened.”  And that’s a use-site
> concern.  ArrayList<BigValue?> gives you that.
> 
> Which is to say: the claim that V? is useless once we have reified generics is
> simply untrue.

i've said this is a corner case,
anyway i don't get this example given that both our proposal work the same on this example, N? is the L view of a value type in both proposal, we only differ on the way we interact with the type system, at the VM level, both proposal are equals.

Rémi

> 
>> On May 1, 2019, at 10:32 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>> 
>> On 5/1/19 10:12 AM, Brian Goetz wrote:
>>> 
>>> You’re assuming the utility of V? after reification is zero, but
>>> that’s not the case. For example, suppose ArrayList is reified.  Then
>>> the user gets the choice of erasure or reification by selecting
>>> ArrayList<V?> or ArrayList<V>. Erasure has a bad rap, but sometimes
>>> it is desirable.
>> 
>> As I tried but failed to get across in post on sorting, choosing V vs V?
>> can lead to 5X cost differences in *either direction* for common
>> aggregate (collection and array) operations. So programmers will need to
>> learn some of these consequences. (Which is made harder/worse here
>> because the cost tradeoffs will probably change over time as VM support
>> improves.)
>> 
>> Which is mainly an argument for Brian's position, except for those who
>> believe that Java programmers should not have to encounter these kinds
>> of issues that C++, C#, OCAML, etc programmers face all the time;
>> betting that somehow VMs will make the right choice.
>> 
>> (Maybe this is not the right time to mention this, but most other
>> languages supporting this range of use have a middle-ground of
>> call-by-ref for extracting small parts of large things, as seen in
>> comparators, hash-codes, etc that can make a big performance difference.
>> I expect people will complain about not supporting this.)
>> 
>> -Doug
>> 
>>