Proposal: Accepting a subclass as an element type in a for loop (original) (raw)

Ulf Zibis Ulf.Zibis at gmx.de
Tue Mar 31 06:10:25 PDT 2009

+1

-Ulf

Am 31.03.2009 14:55, Jean-Louis Ardoint schrieb:

I'm maybe a bit too late. Here's my proposal anyway.

-- Jean-Louis Ardoint Accepting a subclass as an element type in a for loop AUTHOR(S): Jean-Louis Ardoint OVERVIEW FEATURE SUMMARY Add a filtering and downcast capability to the enhanced for statement (a.k.a for each). MAJOR ADVANTAGE It should reduce the number of lines of code and depth of nesting in loops. The resulting code would be more readable that what is done currently to achieve the same goal. The meaning of such a loop is quite obvious. MAJOR BENEFIT Better readability and expressiveness. MAJOR DISADVANTAGE More complexity in the compiler to generate a little bit more bytecode. ALTERNATIVE You can currently the same thing, yet it means adding an extra if statement and an intermediate variable to be cast. EXAMPLES Here is a small not very interesting example of such a enhanced for loop: Shape[] shapes = ...; for (Shape s : shapes) drawShape(s); If for a reason you would need to draw only the rectangles, you would need to write: for (Shape s : shapes) { if (s instanceof Rectangle) drawRectangle((Rectangle)s); } This is not very aesthetic. If only the for loop would directly accept a subclass as the element type and do the type checking and downcast, we could be able to write: for (Rectangle r : shapes) drawRectangle(r); Note that there is a subtlety w.r.t. the handling of nulls. See Compilation below for more details DETAILS SPECIFICATION: The grammar is unchanged. The equivalence between an enhanced for loop and a regular for loop has to be changed in JLS 14.14.2. COMPILATION: The way enhanced loop are translated into bytecode would change depending on whether the loop variable type is a subclass of the iterable or array element type. If the loop variable type is a subclass, then the loop is equivalent to: For an expression returning Iterable: Iterable cs... for (I #i = cs.iterator(); #i.hasNext(); ) { C #c = #i.next(); if (#c == null || #c instanceof D) { D d = (C)#c; ... } } For an array: C[] ca... for (int i = 0; i < ca.length; i++) { C #c = ca[i]; if (#c == null || #c instanceof D) { D d = (C)#c; ... } } Note that we need to test against null to keep the same behavior as the regular enhanced for loop. TESTING: This feature can be tested in the same way the enhanced for loop is tested.

LIBRARY SUPPORT: There is no need for library support. REFLECTIVE APIS: No updates to the reflection APIs are needed. OTHER CHANGES: No other changes are needed. MIGRATION: Migration of existing enhanced for loop can be done if one desires so. COMPATIBILITY BREAKING CHANGES: This feature would not break any existing programs, since the new feature only permits more code to be parsed than before. EXISTING PROGRAMS: Class file format does not change, so existing programs can use class files compiled with the new feature without problems.

More information about the coin-dev mailing list