Proposal: Indexing access syntax for Lists and Maps

[Joseph D. Darcy]

Hello.

Shams Mahmood wrote:
> Indexing access syntax for Lists and Maps
>
> VERSION
> This is version 1.0.
>
> AUTHOR(S):
> Shams Mahmood Imam
>
> OVERVIEW
>
> FEATURE SUMMARY:
> Collection classes are among the most frequently used in the Java SDK.
> Currently Lists and Maps do not provide any additional language 
> feature to access individual elements unlike Arrays. This proposal 
> aims to provide these Collection citizens of java additional 
> language support to access elements like Arrays have currently. 
>   

I was going to type up a proposal along these lines from scratch, but 
I'm happy you sent in your proposal first, especially since there is a 
prototype already :-)

While collections are certainly very widely used and should have this 
indexing support IMO, I think it is also important that indexing support 
not be strictly limited to just classes implementing java.util.{List, 
Map}.  For example, if this kind of capability is added, I'd like enough 
flexibility to give library developers the ability to in effect write a 
64-bit array class.  (Semantically, a Java array today is basically just 
a map from int to some other type.)

The mechanism to indicate indexing is supported on a class must at least 
support Lists and Maps:

java.util.List<E>
read:   E get(int)
write:   E set(int, E)

java.util.Map<K, V>
read:   V get(Object)
write:   V put(K, V)

So variation in both the names of the methods must be accommodated as 
well as the typing of the methods.

The compiler needs a few pieces of information to perform the indexing 
translating including "Should this type get indexing support?" and "If 
this type gets indexing support, what methods do read and write 
operations get mapped to?"

The most magical way to indicate the indexing support bit is to have a 
marker interface (or even an annotation) and then to have the names of 
the get/set methods indicated as annotation values.  As a strawman 
something like

    public interface java.lang.Indexable {}

    @Documented
    @Target(TYPE)
    @Retention(RUNTIME)
    @Inherited
    public @interface java.lang.IndexableNames {
        String reader() default "get";
        String writer();
    }

where then, say, java.util.List would be changed from

    public interface List<E> extends Collection<E>

to

    @IndexableNames(writer="set")
    public interface List<E> extends Collection<E> extends Indexable

However, this feels a bit too magical and there would be complications 
about getting the indexable method names since annotation inheritance 
only works along superclasses, not superinterfaces.

A better approach is probably to create at least two new superinterfaces 
in java.lang for the List and Map signatures.  However, some care and 
analysis will be needed to ensure a migration compatibility issue is not 
introduced.  (In support of the enhanced for loop in JDK 5, a 
superintface of java.util.Iterator, java.lang.Iterator (lacking a remove 
method), was introduced being being subsequently removed for migration 
compatibility conflicts.)

-Joe