Simply implicit method chaining

[Ulf Zibis]

AUTHOR(S): Ulf Zibis, Cologne, Germany

OVERVIEW
FEATURE SUMMARY: Simply implicit method chaining.
MAJOR ADVANTAGE:
- Avoids casting in many situations.
- Code would become more legible.
MAJOR BENEFIT:
This proposal would programmers motivate to write short, compact and 
best legible code. Because of the need of casting, programmers often 
avoid the method-chaining, as it sacrifices one legibility win against 
an other. Additionally Semantic of, in fact, void methods would become 
more clear.
Secondly legibility would increase, if multiple repetition of initial 
referred instance identifier could be avoided.
MAJOR DISADVANTAGE:
Many existing methods should be reviewed, by refactoring return types to 
void, to profit from this feature.
ALTERNATIVES: No

EXAMPLES
SIMPLE EXAMPLE:
After this change:
        CharBuffer X = 
CharBuffer.allocate(26).position(2).put("C").position(25).put("Z");
Before this change:
        CharBuffer X = ((CharBuffer)((CharBuffer)CharBuffer.allocate(26)
                .position(2)).put("C").position(25)).put("Z");
    or:
        CharBuffer X = CharBuffer.allocate(26);
        X.position(2);
        X.put("C").position(25);
        X.put("Z");
Comment: nit-pickers would say, that position(int pos, char c) could be 
used in this example, but everyone who has ever worked with nio buffers 
should know, of which worries I'm speaking about.
ADVANCED EXAMPLE:
After this change:
        String mySub = myVeryLongNamedString.subString(.indexOf("C"), 
.indexOf("Q"));
Before this change:
        String mySub = myVeryLongNamedString.subString(
                myVeryLongNamedString.indexOf("C"), 
myVeryLongNamedString.indexOf("Q"));

DETAILS
SPECIFICATION:
Grammar should allow that method invocation could refer backward to 
instance of initial identifier.
'.' starting expressions should refer to initial identifier.
COMPILATION:
Compile:
        CharBuffer X = 
CharBuffer.allocate(26).position(2).put("C").position(25).put("Z");
to:
        CharBuffer X = CharBuffer.allocate(26);
        X.position(2);
        X.put("C");
        X.position(25);
        X.put("Z");
Compile:
        CharBuffer X = CharBuffer.allocate(26);
        CharBuffer Y = X.position(2);
to:
        CharBuffer X = CharBuffer.allocate(26);
        CharBuffer Y = X;
        Y.position(2);
Compile:
        String mySub = myVeryLongNamedString.subString(.indexOf("C"), 
.indexOf("Q"));
to:
        String mySub = myVeryLongNamedString.subString(
                myVeryLongNamedString.indexOf("C"), 
myVeryLongNamedString.indexOf("Q"));

Compiler should skip castings from legacy code.
Class file format would not be affected.
Bytecode would not be affected.
TESTING:
Compiler should compile given examples without errors.
Bytecode of 1. example should be same than before if casting would be 
eliminated.
Bytecode of 2. example should be identical.
LIBRARY SUPPORT: No supporting libraries are needed for the feature?
REFLECTIVE APIS: There should not be any affection to reflection API.
OTHER CHANGES:
Legacy API methods returning this should be refactored to void.
A list of affected APIs should be published (see MIGRATION).
MIGRATION:
A list of refactored APIs should be published. To take advantage of this 
change, programmers should scan their code base for usage of those APIs, 
and refactor the regarding statements manually or by usage of regex 
patterns. Anyway no refactoring is needed to stay compatible.

COMPATIBILITY
BREAKING CHANGES:
No previously valid programs are now invalid.
EXISTING PROGRAMS:
Source and class files of earlier platform versions interact with the 
feature without any notice.

REFERENCES
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000107.html
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=15541&forumID=1463
EXISTING BUGS:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6451131
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4774077
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=799586
URL FOR PROTOTYPE (optional):