Hi Guy and Paul,
thanks for liking my proposal.
What can we do to convince the "officials" ?
-Ulf
Am 26.03.2014 17:20, schrieb Paul Benedict:
It would be nice to make this language change. In the past years, it's pretty clear many JSR EE
spec leads have gone on to make their APIs return the same object because they strongly prefer to
see object chaining in code. I sympathize with those designers, but I don't agree; I wouldn't
affect my API just for the sake of chaining. For the sake of clarity, I prefer functions that
don't compute anything to return void. So +1 for the language to figure this out.
On Wed, Mar 26, 2014 at 10:51 AM, Guy Steele <guy.ste...@oracle.com
<mailto:guy.ste...@oracle.com>> wrote:
On Mar 26, 2014, at 4:17 AM, Ulf Zibis <ulf.zi...@cosoco.de> wrote:
> See also:
> . . .
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html
This last one has a specific proposal, which is simple and quite nice. The
important idea is
that we don't actually make any change to the code of void methods or make
them actually
return anything; instead, the caller takes notice of situations where an
invocation of
a void method is used as a subexpression whose value is required
(heretofore forbidden
by the language) and gives it a special interpretation.
I note that Ulf's proposal applies only to method invocations, but I note
that the same
technique could be used to include field references if desired.
I am wholeheartedly in favor of allowing "chaining" of dotted expressions
such as
CharBuffer.allocate(26).position(2).put("C").position(25).put("Z")
I am a bit more skeptical about expressions that begin with a dot because
of potential
confusion about which expression is referred to:
myVeryLongNamedString.subString(.indexOf("C"), .indexOf("Q"))
seems clear enough, but what about:
myVeryLongNamedString.subString(.indexOf("C") + otherString.length(),
.indexOf("Q"))
Does the second occurrence of .indexOf use myVeryLongNamedString or
otherString?
A compromise would be to allow leading-dot expressions to occur only within
the arguments
of the method call whose target is the object which the leading-dot
expressions are expected
to use as their target, and if there are such leading-dot expressions
within the arguments
then the arguments must not contain any non-leading-dot field references or
method calls.
Just a thought for discussion. This would be considered a separate
mechanism from the
chaining-of-void-methods mechanism (it was a very clever idea to try to
unify them in Ulf's
original proposal, though).
---Guy
--
Cheers,
Paul
