Simply implicit method invocation chaining (update)
Ulf Zibis
Ulf.Zibis at gmx.de
Mon Mar 30 14:43:07 PDT 2009
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):
More information about the coin-dev
mailing list