"Model 2" prototype status

[Vitaly Davidovich]

So in that case, considering the static T or Foo<T> members as belonging to
a concrete specialization is actually intuitive, at least to me.  What
would be weird is if the following was somehow handled differently:

class Foo<T> {
    static final T _t;
    static int _x;
}

where is _x and where is _t? How would I reflect over them at runtime?


On Fri, Aug 7, 2015 at 12:54 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Depends what you mean by out.  We are fully aware that this is a desirable
> and useful thing to be able to express, and intend to find a way to do so.
> But we don't think that complicating the semantics of statics is
> necessarily the right way to get there.  It has been suggested (thanks
> Peter) that borrowing the "object" notion from Scala would be a far better
> way to achieve this (and other things) than to change the semantics of
> static, and I'm inclined to agree.
>
> So the code below is probably "out" as written -- but that doesn't mean
> we've given up on solving the underlying problem.
>
>
>
>
> On 8/7/2015 12:46 PM, Vitaly Davidovich wrote:
>
>> I'd like to be able to express the following:
>>
>> class Foo<T> {
>>      static final T _t = ...;
>>      static final Foo<T> _ft = ...;
>> }
>>
>> I guess that's out?
>>
>> On Fri, Aug 7, 2015 at 12:37 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> wrote:
>>
>>     I don't see that there's any other sensible choice.  Asking users to
>>     reason about the partially-heterogeneous translation (where some
>>     instantiations share a class and some do not) in the context of an
>>     existing language feature like static fields would be silly -- and
>>     counterproductive.
>>
>>     (There are other places where the translation will necessarily
>>     intrude; ideally, we want to keep those to reflective features,
>>     those that cut across the language-level type system and the runtime
>>     class system, such as class literals (Foo.class), instanceof,
>>     casting, and reflection.)
>>
>>
>>         I think keeping static fields per-class (in the sense of "the
>>         class the user
>>         wrote down in code", not "some random class artefact the runtime
>>         happened to
>>         emit") would be the most sensible and simple thing to do. No
>>         explanation or
>>         learning necessary, because everything works exactly like it has
>>         the last 15
>>         years in Java.
>>
>>
>>
>>