Implicit 'this' return for void methods

[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> 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