"Model 2" prototype status

[Vitaly Davidovich]

I'm saying it's intuitive (obviously subjective), not saying you need to do
it for java.

Having them shared across some instantiations (Foo<String> and
> Foo<Integer>) but not others (Foo<Integer> and Foo<int>) would be silly and
> definitely not intuitive.


Definitely, not proposing that type of inconsistency.

In Java, statics have always been shared across instantiations (and they
> predate instantiations)


Yup, java never had specialization or anything remotely close to reified
type info either.

But my question stands: given the scenario, where do _t and _x live?
Foo<String>._t vs Foo<int>._t and Foo<String>_x and Foo<int>._x? How would
it work with reflection?

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

> 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.
>>
>
> We've had this discussion several times before, and still no one is buying
> this argument.
>
> Coming from C# (or C++), which have different models for parametric
> polymorphism, it might make sense.  (Even if Java, it might have been
> "intuitive" if we had heterogeneously-translated generics from day one, but
> we didn't.)  In Java, statics have always been shared across instantiations
> (and they predate instantiations).  Having them shared across some
> instantiations (Foo<String> and Foo<Integer>) but not others (Foo<Integer>
> and Foo<int>) would be silly and definitely not intuitive.
>
> Changing the current behavior (making them not shared across any
> instantiations) is completely off the table.  (Do I even have to say this?)
>
> I understand what you want to express, and I agree its valuable that it be
> expressible.  But the path you're trying to sell is not the way to get us
> there.
>