Proposal: Indexing access syntax for Lists and Maps

Shams Mahmood shams.mahmood at gmail.com
Mon Mar 30 06:42:17 PDT 2009


Regarding get/set interface please see my refer to Joe in this same thread.
Re Part of 15.13 and 15.26.1, thanks I will look into it today evening when
I get back home :).
Re Ara syntax to ArrayAccess and CollectionAccess differ - yes the syntax is
very similar. I only added
different Grammar elements as the names can be misleading as now Lists and
Maps will also have subscript
access. AFAIK if you see the kijaro code, I've implemented them in the same
Visitor method that handles arrays.
Will need a complete change in names or clone the Array access node to a
List or Map node in the later
stages of the compilation process once type info can be determined - i.e.
Array, List or Map.

2009/3/30 <rssh at gradsoft.com.ua>

> > 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.
> >
> > MAJOR ADVANTAGE:
> > Will provide a consistent syntax for accessing elements of Arrays,
> > Lists and Maps. In addition, the language grammar will not change
>
>  Often we nee something 'less' than List or Map.
> I. e. I would be good to see i additional to lists and maps some 'minimal'
> get/set interface.
>
> > much since the subscript operator is already supported for Arrays.
> >
>
> ....
> > DETAILS
> >
> > SPECIFICATION:
> > Java Language Specification changes:
> >
> > 15.29 (NEW CHAPTER): Collection Access Expressions
> > A collection access expression contains two subexpressions, the List/Map
> > reference expression (before the left bracket) and the index expression
> > (within the brackets). Note that the List/Map reference expression may be
> > a name or any expression that evaluates to a List/Map. The index
> > experssion is expected to evaluate to an int for Lists and a valid key
> > type for Maps.
> >
> > CollectionAccess:
> >   Expression [ Expression ]
> >
> > 15.8 Primary Expressions
> > original:
> > ---------
> > PrimaryNoNewArray:
> >   Literal
> >   Type . class
> >   void . class
> >   this
> >   ClassName.this
> >   ( Expression )
> >   ClassInstanceCreationExpression
> >   FieldAccess
> >   MethodInvocation
> >   ArrayAccess
> >
> > replaced with:
> > --------------
> > PrimaryNoNewArray:
> >   Literal
> >   Type . class
> >   void . class
> >   this
> >   ClassName.this
> >   ( Expression )
> >   ClassInstanceCreationExpression
> >   FieldAccess
> >   MethodInvocation
> >   ArrayAccess
> >   CollectionAccess
> >
>
>  Ara syntax to ArrayAccess and CollectionAccess difer ?
> If not, this is one expression in grammar
>
>
> > 15.26 Assignment Operators
> > original:
> > ---------
> > LeftHandSide:
> >   ExpressionName
> >   FieldAccess
> >   ArrayAccess
> >
> > replaced with:
> > --------------
> > LeftHandSide:
> >   ExpressionName
> >   FieldAccess
> >   ArrayAccess
> >   CollectionAccess
> >
>
>  The same note as previous.
>
> >
>
> Also JLS contains specifivation of behavious of assigment.
> I changed this specification for class-array-assigment (in simular
> proposal, but more general and annotation-based instead interface-based
> as you)
> http://docs.google.com/Doc?id=dhhvggr8_18djp85shk
>
> Part of 15.13 and 15.26.1 of JLS must be rewritten in you case. (I guess
> you can get this changes from text of my proposal and slightly adopt,
> semantics would be the same)
>
>
>
> > COMPILATION:
> >
> > After successful creation of the AST handling the additional grammar for
> > Collection Access expressions, the syntactic sugar will be replaced by
> > JDK1.4 compatible code during the Code Generation phase. This is
> > consistent with how JDK5.0 constructs like the for-each loop is handled
> by
> > the compiler.
> >
> > e.g.
> > public class TestConcise {
> >   public static void main(String[] args) {
> >     java.util.Map<Integer, String> m1 = new java.util.HashMap<Integer,
> > String>();
> >     m1[2] = "two";
> >
> >     java.util.LinkedList<String> l1 = java.util.Arrays.asList( new
> > String[] {"a", "b", "c" });
> >     m1[3] = l1[2];
> >     l1[0] = m1[0];
> >     l1[1] = "one";
> >   }
> > }
> >
> > is converted to
> > public class TestConcise {
> >   public TestConcise() {
> >     super();
> >   }
> >
> >   public static void main(String[] args) {
> >     java.util.Map<Integer, String> m1 = new java.util.HashMap<Integer,
> > String>();
> >     m1.put(Integer.valueOf(2), "two");
> >
> >     java.util.LinkedList<String> l1 = java.util.Arrays.asList( new
> > String[] {"a", "b", "c" });
> >     m1.put(Integer.valueOf(3), l1.get(2));
> >     l1.set(0, m1.get(Integer.valueOf(0)));
> >     l1.set(1, "one");
> >   }
> > }
> >
> >
> > TESTING:
> >
> > LIBRARY SUPPORT:
> > No additional library support is needed.
> >
> > REFLECTIVE APIS:
> > This proposal does not require any reflective API changes.
> >
> > OTHER CHANGES:
> > No changes required.
> >
> > MIGRATION:
> > No migration is needed.
> >
> > COMPATIBILITY
> >
> > BREAKING CHANGES:
> > No breaking changes.
> >
> > EXISTING PROGRAMS:
> > Existing programs are not affected by this change.
> >
> > REFERENCES
> > My Java7 Wishlist regarding Collections,
> >
> http://shamsmi.blogspot.com/2008/04/my-java7-wishlist-regarding-collections.html
> > Implementation of My Java7 Wishlist,
> >
> http://shamsmi.blogspot.com/2008/05/implementation-of-my-java7-wishlist.html
> >
> > EXISTING BUGS:
> > None.
> >
> > URL FOR PROTOTYPE (optional):
> > Projects kijaro's concisecollections branch:
> >
> https://kijaro.dev.java.net/source/browse/kijaro/branches/concisecollections/
> >
> >
> >
> >
> >
>
>
>


-- 
Shams Mahmood



More information about the coin-dev mailing list