64 bit collections, and API migration in general (was Re: Migrating methods in Collections)

[John Rose]

On Dec 18, 2015, at 8:55 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> 2. It seems irresponsible to spend so much effort on
>> Collections without also somehow addressing 32bit size/index
>> limitations. Yes?

Yes it would be, and we are aware of this question, and expecting
to address it later in the light of prior design choices.

> I think that's really a separate question.  While everything said so far is Collection-specific, it's not really "so much effort on Collections" as much as "so much effort to ensure that legacy libraries can be compatibly anyfied", and that Collections is the poster child for that effort.  (If we can't migrate Collections, that's evidence that we're still lacking in linguistic tools for supporting the transition to anyfied generics.)
> 
> So I'll interpret your question as: "These are nice migration tools for migrating erased libraries to anyfied, but there are other migrations we'd like to perform on these aging libraries, please don't forget about them?"
> 
> The migration in question is whether we can compatibly migrate methods like:
> 
>    get(int index)
> to
>    get(long index)

"Two instances" is always a suspected hiding place for "more than one instance".
For example, an APL-like matrix can be viewed as a linear (ravel-able) collection
indexed by int-pairs, which are neither ints or longs.

I am assuming (until proven wrong) that the move from int to long should be part
of a larger move from int to Index, where Index is an any-fied generic parameter.

The practical effect of this concern, at the present moment, is that we should
not only look at APIs which mention "Object" as suspects for any-fication,
but also APIs which use "int" as an index.  An "int" index is a candidate for
replacement with some type "Index".  It is *not* (IMO) likely to be a good
candidate for ad hoc introduction of sibling "long" overloadings.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20151221/8feb7cb3/attachment.html>