"Model 2" prototype status

[Martijn Verburg]

Hi Timo/all,

I appreciate that a particular syntax can make it more difficult to
understand the semantics of something as complex as this proposal (I had to
stop myself from commenting on parts I didn't like), but the assumption
that 'You really get a sense that there is no overall design behind this
syntax backing it up.' is (to be blunt) not helpful. Brian's original email
clearly showed a lot of time, effort and design has gone into this proposal
and I'm personally happy that we get an early look at these things so we
can find holes in the semantics :-).  We can argue/fix/review Syntax easily
towards the end, altering javac for syntax isn't going to be the hard part.

I'd encourage people to spend a good length of time exploring this
proposal, try samples out on their own code, think long and hard about the
underlying interactions between Generics (wildcards in particular), the
proposed concept of Any, how primitives might play into this etc. This is
actually some pretty good intellectual fodder for a series of brown bag
sessions with colleagues (I'm itching for whiteboard markers right now). As
a reminder: http://openjdk.java.net/projects/valhalla/ outlines some of the
suggested participation/feedback which will be most helpful.



Cheers,
Martijn

On 2 August 2015 at 21:55, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:

> Hi,
>
>
>
>
> 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,
> Timo.
>
> 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
> >to
> >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
> >yet.
>
> 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 :(
>
> Rémi