Re: "Model 2" prototype status
timo.kinnunen at gmail.com
Sun Aug 2 20:55:56 UTC 2015
Re: “I don't care about the syntax but the one you propose doesn't help IMO.”
I have to agree. You really get a sense that there is no overall design behind this syntax backing it up.
For example, my current source of confusion is whether A<any T> is to be interpreted as A<ref T | any T | null> or as A<ref T | any T | !(null)>. (A note on the syntax being used: the presence or absence of the nulltype amongst the bounds is to be interpreted literally.)
Seeing “Alternately, you can interpret "any T" as a union bound ("T extends Object | value")” suggests it’s the first interpretation that’s correct but then seeing “ Some operations that are allowed on ordinary tvars are not allowed on avars, such as assigning a T to an Object, assigning null to a T, etc.” suggests the correct interpretation should be the latter.
A properly designed syntax where such semantics can be expressed in a natural way will be helpful to have, one year from now. Would be much more helpful to have it right now though, IMHO…
Have a nice day,
Sent from Windows Mail
From: Rémi Forax
Sent: Sunday, August 2, 2015 21:52
To: Brian Goetz, valhalla-dev at openjdk.java.net
Le 1 août 2015 23:48:07 CEST, Brian Goetz <brian.goetz at oracle.com> a écrit :
>> I dislike the Foo<ref> / Foo<any> thing for several reasons.
>Not surprising. This wasn't our first choice either.
>We spent a great deal of effort investigating whether it was possible
>re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref
>tvar, and to mean Foo<any> when the corresponding tvar is an any tvar.
>Seems obvious, right?
It's not what i propose.
Foo<any> is Foo<any>.
Foo<ref> is Foo<?> because if Foo<?> is used in a 1.10 class file it's a reified type and if Foo<?> is used in a 1.9 class the compiler considers that is not reified and disallow to cast by example a Foo<any> to a Foo<?>. Practically, in that case, a user can use something similar to a checked collection that will check at runtime that each value have the right class.
>Several hundred hours later, the short answer is that things fall apart
>when a library is any-fied and the client is not recompiled; this would
>make any-fication a binary-incompatible change, which would be a loser.
> So with tears in our eyes, we reluctantly concluded that we needed to
>differentiate between Foo<ref> and Foo<any>. Once we swallowed that
>pill, many things snapped into place. So as sad as it is to have two
>kinds of wildcard, I'm pretty sure its the right call.
I understand the need of differenciating between Foo<ref> and Foo<?> but i hope that instead of having to explain that to each Java dev, we can explain that only to the few that will stumble on the issue.
>You prefer another syntax? Sure, I'm sure there are alternatives. We
>can talk about it -- but not this year! We have way more important
>things to work out before that comes anywhere near the top of the list.
I don't care about the syntax but the one you propose doesn't help IMO.
>As to bounds... we're still working out the details of the interaction
>between value types and interfaces. So its quite possible that Foo<any
>T extends Comparable> may in fact be meaningful. (And if that's the
>case, primitives might join the party too.) Or not, we're not sure
yes, forget the interfaces,
i suppose that it's not a big deal to not try to support them until you want to introduce value types in a later release :(
More information about the valhalla-dev