Implicit 'this' return for void methods

Ulf Zibis Ulf.Zibis at CoSoCo.de
Thu Mar 27 16:24:35 UTC 2014


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.steele at oracle.com 
> <mailto:guy.steele at oracle.com>> wrote:
>
>
>     On Mar 26, 2014, at 4:17 AM, Ulf Zibis <Ulf.Zibis at 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




More information about the core-libs-dev mailing list