Method calls vs lambda calls

[Stefan Schulz]

Alex Blewitt wrote:
> 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.

Are you confusing lambdas with function-typed variables here? To my 
understanding, any function-typed variable has to follow the namespace 
rules because of conflict and hiding issues.

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

This would not work with local and method variables.

>    protected final double trouble = #int(int a) { a*2 };

I assume you meant the following:
   #double(int) trouble = #(int a) ( a*2 );

(Not sure, if the compiler takes int to double compatibility.)

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

Which would only cover a tiny use-side of directly invoking a stored 
lambda via a method. I don't see the use-cases of such an approach, as 
it is always possible to write a wrapping method in this case.

Stefan