Method calls vs lambda calls

[Howard Lovatt]

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

property #int() ft = #int() (41);

What the compiler actually produced was:

private #int() ft = ftInit();
public #int() initFt() { return #int() (42); }
public final #int() getFt() { return ft; }
public final #int() setFt( final #int() ft ) { this.ft = ft; return ft; }
public final int ft() { return ft.call(); }

And the following translations were also performed by the compiler:

You write        -> Compiler outputs
ft = #int() (42); -> setFt( #int() (42) );
#int() i = ft;      -> #int() i = getFt();

And in a derived class if the property is initialized to a different
value, i.e. you write "property #int() ft = #int() (43);" in a derived
class then the compiler outputs:

@Override public #int() initFt() { return #int() (43) };

in the derived class.

Anyway I thought this too big a change and that a function-type
variable having to be a property was odd and hence suggested just
putting the name in both name spaces as easier (but not actually
generating the method). Putting the name in both spaces, as I said
before, also has some undesirable effects.

All in all, I think it best to forget about function-type variables altogether.