Indexing access syntax for Lists and Maps

[Shams Mahmood]

I was wondering whether there has been any update on the indexing feature for Collections? I recently came across Brian Goetz's update on Project Lambda (http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html). It looks like the support for default methods in interfaces can help implement this feature relatively easily:

  package java.lang;
  /**
   * All classes implementing this interface will have compiler support
   */
  interface Indexable<KeyType, ValueType> {
    ValueType getAtIndex(KeyType index);
    ValueType setAtIndex(KeyType index, ValueType value);
  }
  
  package java.util;
  interface List<T> extends Indexable<Integer, T> {
   ...
    T getAtIndex(Integer index) default { get(index); }
    T setAtIndex(Integer index, T value) default { set(index, value); value; }
  }
  interface Map<K, V> extends Indexable<K, V> {
    ...
    V getAtIndex(K index) default { get(index); }
    V setAtIndex(K index, V value) default { put(index, value); value; }
  }

With these interfaces in place the compiler can now desugar the calls for Lists and Maps or similarly implemented classes as:
  myList[1] = myList2[2] = myList3[3];
as:
  myList.setAtIndex(1, myList2.setAtIndex(2, myList3.getAtIndex(3)));

Does this sound reasonable? It addresses issues (2), (3) and (4) mentioned below by Reinier.

Also, we can possibly can split the interface Indexable into two separate interfaces for readable and writable views to allow users to allow supporting only specific indexing operations. 

Shams.

> Greg, reread some older threads. We've held an extremely extensive  
> back-and-forth about implementing map/list index operators. A summary  
> of the findings:
> 
> 1. Whatever we come up with, it has to work with java.util.Map and  
> java.util.List, otherwise, why bother? Map and List are both  
> interfaces, so they cannot gain any new methods. Therefore, either (A)  
> we 'hardcode' support in for those data types, or (B) we come up with  
> an interface that mirrors a strict subset of the methods in those types.
> 
> 2. Mirroring List's "T get(int)" is just fine, but "boolean set(int,  
> T)" is problematic because of that 'boolean' return value. What should  
> this:
> 
>   Object x = someArrayList[0] = "Hello";
>   System.out.println(x);
> 
> ...
> 
> 3. Same situation (but worse) with Map: "V get(K)" is fine, but "V  
> set(K, V)" is problematic, as it returns the OLD value associated with  
> the key (usually null, in other words). So:  
> System.out.println(map[key] = "Hello"); will print 'null', not  
> 'Hello'. Puzzler. Bad.
> 
> 4. Technically, the result of the "a = b" expression in the JLS is  
> defined as not just "b", but "b, converted to fit into a". So:
> 
> long foo;
> Object x = foo = 1;
> System.out.println(x.getClass());
> 
> will print "java.lang.Long" and not "java.lang.Integer" as you might  
> expect...
> 
> 5. Even though I consider the value of this proposal very low (who  
> indexes into lists? You .add(), and you iterate), Joe Darcy continues  
> to mention this proposal in coin posts, so apparently it isn't dead yet.
> 
>   --Reinier Zwitserloot