Implicit 'this' return for void methods
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" ?
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
> 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).
More information about the core-libs-dev