State of the Lambda

Joshua Bloch jjb at
Thu Jul 8 16:16:35 PDT 2010


Yes; your proposed syntax would alleviate this concern.


On Wed, Jul 7, 2010 at 11:25 PM, John Rose <john.r.rose at> 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) -> } 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.

More information about the lambda-dev mailing list