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

Shams Mahmood shams.mahmood at gmail.com
Mon Mar 30 06:38:07 PDT 2009

Hi Joe,

Haven't used too many annotations in Java code. I had fiddled with the idea of Indexable (yes even I had come up with the same name - our vocabularies are so limited ;) ), but I decided otherwise for the following reasons:

  1. Java traditionally has wanted to avoid operator overloading (Indexable means compiler providing operator support for Indexable marked classes). Although for each loops have special handling cases for Iterable types.
  2. get/set implementation of Lists and Maps will need to change. In fact Map doesn't even have a set, so a new method will be added to the interface breaking backwards compatibility.

Shams.

On Mon, Mar 30, 2009 at 2:48 AM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:

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 extends Collection to @IndexableNames(writer="set") public interface List extends Collection 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

-- Shams Mahmood

-- Shams Mahmood

More information about the coin-dev mailing list