Method calls vs lambda calls

[Stefan Schulz]

Neal Gafter wrote:
> On Wed, Dec 16, 2009 at 6:36 AM, Stefan Schulz <schulz at the-loom.de
> <mailto:schulz at the-loom.de>> wrote:
>     I didn't say anything about making a method. If the short-hand
>     invocation syntax is allowed, putting names of function-typed variables
>     in the same (scope-relative) space like methods is a way to ensure not
>     to have methods and function-typed variables with the same name.
>
> I'm afraid it doesn't ensure that at all.  Because methods may overload,
> a given scope may have many definitions for a given name in the method
> namespace.

Too bad. Is there any possibility to hold the full signature of methods 
and function-typed variables in some way to being able to resolve these 
conflicts? Maybe an additional function space? Sorry, if this sounds a 
bit naive.

>     As this
>     has to hold for inheritance, too, I do not see a problem in
>     function-typed variables of subclasses to @Override those of a
>     superclass, as the information is already there. (Of course, they must
>     additionally hide normal variables having the same name.)
>
>
> What semantics are you imagining for this overriding?  What if the thing
> being overridden is a method?

I didn't mean to being able to override methods with function-typed 
variables, or vice versa (although this sounds interesting).

So, what would be the conclusion?
* If any method m exists in a class's hierarchy, one cannot define a 
function-typed field m?
* If a function-typed field m exists in a class's hierarchy, one cannot 
define a method named m?
* If a function-typed field m exists in a class's hierarchy, will a 
field named m (of any type?) in a subclass hide the function-typed field m?
* If a non-function-typed field m hides a superclass's function-typed 
field m, would it be possible to define a method named m in that very 
subclass?

Stefan