more background to List<int> specializing List<Any>
brian.goetz at oracle.com
Sun Jan 4 23:20:03 UTC 2015
More likely: if we took value types out of the picture, we might well
not bother with specialization at all; we've limped along without it for
a long time, and there have been other solutions (Trove, GS-Collections)
that provide 80% of the value of primitive-specialized collections for
like 1% of the work. But value types tip the balance from "unpleasant
but tolerable with grumbling" to "unacceptable."
Zooming back, though, I think what you're really saying is: the part
where List<int> is not a subtype of List is really the part you dislike
the most, because it lives in this weird middle ground between "all
instantiations of List<T> have a common supertype" (Java 5 generics) and
"no instantiations of list<T> have a common supertype" (C++). You are
probably OK with either all (what you've got now) or nothing (if you
hadn't had ten years of Java generics training you on homogeneous
translation), but what really freaks you out is this half-here,
half-there, that forces the user to be aware that reference
instantiations are erased and value instantiations are reified, with all
Is that really your concern here?
On 1/4/2015 6:00 PM, Stephen Colebourne wrote:
> The specialization document include the phrase "If we were concerned
> only about primitive instantiations, we could consider some sort of
> "tagged fixnum" approach. However, this approach essentially reverts
> to boxing for arbitrary value types, so it does not get us to our
> Should we take that to indicate that if value types were taken out of
> the picture, and the only goal was to handle the existing 8 primitive
> types, that there might be a potentially simpler solution - one where
> List<int> could be a sub-type of List<Integer> without boxing?
> On 4 January 2015 at 18:40, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> I know our focus in this current phase is on "Layers", but would like to
>>> educate myself further about the general background of issues with Any.
>> Let me correct slightly. We're investigating "layers" or "conditional
>> methods" not because this is the feature we went looking for, but because it
>> is a possible and believed-practical answer to the more general question of
>> "what generic type system can provide us the gradual migration compatibility
>> we are looking for."
>> This is not unlike what happened in 8; we didn't do default methods because
>> we wanted multiple inheritance of behavior; we did it because we needed
>> *interface evolution*, and of the dozen or so possible ways to get there
>> that we evaluated, this one had the best combination of characteristics.
>> So far we've gotten feedback that people don't like the balance of "user
>> model weight" and "general utility" for layers (feedback received loud and
>> clear, no need to reopen this.)
>> More generally, I think there's a lot of tendency to assume here that these
>> writeups constitute *decisions*, which they do not. These writeups are
>> snapshots of where our head is at this week, which we provide so people can
>> get a peek about what we're thinking about. But we're a long way from the
>> end of this road.
More information about the valhalla-dev