----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Doug Lea" <d...@cs.oswego.edu> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@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 <d...@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 >> >>
