"Model 2" prototype status
vitalyd at gmail.com
Fri Aug 7 17:31:47 UTC 2015
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
More information about the valhalla-dev