State of the Lambda
Joshua Bloch
jjb at google.com
Thu Jul 8 16:16:35 PDT 2010
John,
Yes; your proposed syntax would alleviate this concern.
Josh
On Wed, Jul 7, 2010 at 11:25 PM, John Rose <john.r.rose at oracle.com> wrote:
> On Jul 7, 2010, at 2:56 PM, Joshua Bloch wrote:
>
> > I'm a little bit worried that method references with receiver variables
> do
> > an copy. ... A possible solution is to require such receiver
> > variables to be (implicitly) final.
>
> This is one of those times where syntax might imply something deep about an
> expression. Brian's sketch uses a prefix "#" to introduce a method lifted
> to a function (and perhaps partially applied to a receiver).
>
> The prefix looks like it might govern the evaluation of the expression to
> the right. An infix operator would much more clearly express that the left
> hand side of the expression (at least) is evaluated in the normal
> left-to-right order of Java expressions. (Some infix operators, ?: && ||
> have special rules for evaluation order, but it only applies to the right of
> the operator.)
>
> An infix formulation would make it clearer that the qualifier LHS is a
> normal expression:
>
> foo # bar
> baz[++n].bang() # bar
>
> This means that foo#bar is not equivalent to { (T x) -> foo.bar(x) } if foo
> contains side effects or is affected by them.
>
> -- John
>
> P.S. FWIW, I prototyped the foo#bar syntax as a test for JSR 292, which
> includes an extended 'ldc' bytecode which can materialize arbitrary method
> constants. See the bottom of the patch for a unit test file which exercises
> a similar syntax.
>
> http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth-ldc-6939203.patch
>
>
More information about the lambda-dev
mailing list