Proposal: Indexing access syntax for Lists and Maps (original) (raw)

Joseph D. Darcy Joe.Darcy at Sun.COM
Mon Mar 30 00:48:28 PDT 2009

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 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

More information about the coin-dev mailing list