Method calls vs lambda calls

[Alex Blewitt]

On Tue, Dec 15, 2009 at 3:05 PM, Mark Thornton <mthornton at optrak.co.uk> wrote:
>>>> A simple solution would be to specify that method valued fields are in
>>>> the method namespace. Your example would then not compile. I think this
>>>> would be preferable to having different syntax to discriminate between the
>>>> method call and invoking a field.
>
> Howard Lovatt has suggested putting method references in both namespaces
> which would solve that problem.

For all lambdas, or just those defined at the top level of a class? It
must be the latter, surely; they are always visible in a class (other
than shadowing), whereas variables of type lambda could be created in
nested recursive calls on the stack.

Rather than putting them in the namespace itself, why not synthesise a
bona fide method for them if lambdas are in the top level of a class?

public class Example {
  protected final double trouble = #int(int a) { a*2 };
  protected final /* ACC_SYNTHESIZED */ double trouble(int b) {
apply(trouble,b) };
}

That way, it would be visible/understandable by other clients who
would use that class (even if they didn't know about lambdas).

I'm assuming here that we have an apply() keyword of some flavour
which takes varargs that lets lambdas be evaluated in line. We'd need
that in the case that the 'trouble' wasn't final (i.e. could be
updated at a later stage) - clearly, that can't happen for the method
variant.

This would also address the concern of having a (top-level) method
with the same name as a lambda variable.

Alex