Thoughts on peeling and readability
Brian Goetz
brian.goetz at oracle.com
Sat Dec 12 17:14:54 UTC 2015
Without being drawn into a "draw the line" exercise ... that's almost
certainly on the other side of the line.
"Just specific instantiations" is a pretty compelling place to start --
and probably end -- because they map directly to the underlying VM type
system. HashMap<erased> maps to a distinct runtime type;
HashMap<int,int> also does; HashMap<K, V extends Comparable<? super K>>
does not. (Also, if you allow separate specializations of
HashMap<String, any> and HashMap<any, String>, which do you use for
HashMap<String, String>? Now you need runtime "most specific"
analysis. Yech.)
Once you cross the line of "specific instantiations", now you're asking
the runtime to redo a lot of computation that we'd like to leave in the
static compiler. This seems to be entering the "bad return on
complexity" portion of the curve.
On 12/12/2015 4:29 AM, Richard Warburton wrote:
> Hi,
>
> Yes, there are thoughts and plans :) But we're focusing first on
> the "how do I write a fully generic ArrayList" first, and then
> we'll turn to how this could be further hand-optimized for
> specific instantiations.
>
> (It's worth noting, though, there are actually not that many
> concrete examples. ArrayList<boolean> is an obvious one, as is
> HashMap<int,int> (the literature is full of optimized Map
> implementations for this case.) And things like Optional<ref>,
> which can have a more compact representation than Optional<int>.
> Beyond this, the "obvious" examples tail off pretty quickly.
>
>
> Are you able to comment on whether you plan to offer more flexible
> specialization plans than just specific instantiations? For example is
> providing a specialization for the generic type HashMap<K, V> where K
> = V on the cards?
>
> regards,
>
> Richard Warburton
>
> http://insightfullogic.com
> @RichardWarburto <http://twitter.com/richardwarburto>
More information about the valhalla-dev
mailing list