Method calls vs lambda calls

[Neal Gafter]

On Wed, Dec 16, 2009 at 6:36 AM, Stefan Schulz <schulz at the-loom.de> wrote:

> Howard Lovatt wrote:
> >> If function-typed variables are in the method name scope, why should not
> >> ft be overridden in the same way that f is overridden?
> >
> > Alex Blewitt also touched on this point, you can't actually make a
> > method called ft because you could assign a different lambda to it
> > which would require the methods body to change. As I said in the
> > previous post you could do this via something like properties (which
> > have to be fields), e.g. assume that properties were automatically
> > generated by the compiler (like Scala) and that when you 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.


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