Simply implicit method invocation chaining (update)

[Joseph D. Darcy]

Catching up on proposal responses, if one of the problems this proposal 
is meant to address is overly-long variable names, a much simpler 
solution is to use a local variable with a short name!

While fluent interfaces are fine, I don't think using a language change 
to retrofit this pattern of API usage on code not written that way is 
the best use of the language change budget.

-Joe

Ulf Zibis wrote:
> AUTHOR(S): Ulf Zibis, Cologne, Germany
>
> OVERVIEW
> FEATURE SUMMARY: Simply implicit method invocation 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 most right suitable object identifier, if direct preceding method returns void.
> '.' starting expressions should refer to most right suitable object 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):
>
>
>
>
>
>
>