Proposal: Indexing access syntax for Lists and Maps

[Shams Mahmood]

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



-- 
Shams Mahmood



-- 
Shams Mahmood