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

Shams Mahmood shams.mahmood at gmail.com
Mon Mar 30 06:32:04 PDT 2009

The proposed syntax for Set seems counter intuitive to me. While in the case of Arrays, Lists and Maps it will be to access the elements the Set ones will perform a contains check. Perhaps this should be proposed in a separate proposal with a different operator. e.g. set?[x]

---------- Forwarded message ---------- From: Tim Keith <tim.keith at gmail.com> To: coin-dev at openjdk.java.net Date: Sun, 29 Mar 2009 22:40:31 -0700 Subject: Re: Proposal: Indexing access syntax for Lists and Maps Is it possible to include Set as well?

E.g. "bool = set[x]" meaning "bool = set.contains(x)" and "set[x] = bool" meaning "bool ? set.add(x) : set.remove(x)"

-- Tim

On Sun, Mar 29, 2009 at 5:12 PM, Shams Mahmood <shams.mahmood at gmail.com> 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. MAJOR ADVANTAGE: Will provide a consistent syntax for accessing elements of Arrays, Lists and Maps. In addition, the language grammar will not change much since the subscript operator is already supported for Arrays. MAJOR BENEFIT: Apart from the consistency mentioned above, implementation fo this feature will result in fewer characters needed to be typed to achieve simple access to elements in Maps/Lists. MAJOR DISADVANTAGE: Like the for-each loop construct, it will expose the client to NullPointerException(NPE)s when used with a null List/Map. However, this shouldn't be such a major issue as NPEs are also generated by arrays when the operator is used in a null array. ALTERNATIVES: The comparatively more verbose get/set methods for Lists and get/put methods for Maps. EXAMPLES SIMPLE EXAMPLE: public class Main { public static void main(String[] arguments) { List l1 = Arrays.asList(new String[] {"a", "b", "c"}); String firstElement = l1[0]; Map<Integer, String> m1 = new HashMap<Integer, String>(4); m1[Integer.valueOf(1)] = "One"; } } ADVANCED EXAMPLE: public class Main { public static void main(String[] arguments) { List l1 = Arrays.asList(new String[] {"a", "b", "c"}); Map<Integer, String> m1 = new HashMap<Integer, String>(4); Map<String, Integer> m2 = new HashMap<String, Integer>(4); m2[l1[2]] = m2[m1[1]] = 4; // same as m2.put(l1.get(2), m2.put(m1.get(1), 4)); } } 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 15.26 Assignment Operators original: --------- LeftHandSide: ExpressionName FieldAccess ArrayAccess replaced with: -------------- LeftHandSide: ExpressionName FieldAccess ArrayAccess CollectionAccess

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