anonymous method call
forax at univ-mlv.fr
Sun Jun 2 06:07:08 PDT 2013
On 06/02/2013 06:43 AM, John Rose wrote:
> On Jun 1, 2013, at 2:32 PM, Remi Forax <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> wrote:
>> This rule is awful because it means that if you add a method in a class
>> (or worst in a super class)
>> you may broke an already existing code because you introduce a method
>> that will be used instead
>> of calling the lambda.
>> so this syntax was rejected by the Expert Group :)
> OK, this calls for a Devil's Advocate exercise:
> We did something like this before with an iron-clad compatibility
> story. Varargs and autobox were compatibly introduced by adding them
> as post-passes after a presumably failed overloading resolution
> This rule could also (in principle) be applied to method name
> resolution, as a post-pass after presumably failed scoping.
> I.e., if the method name 'foo' in foo(...) cannot be found, then
> attempt to find a variable name foo, which must then be typed as a
> functional type (or jli.MethodHandle? or jlr.Method?) and elide the
> superfluous name (something like 'apply' or 'invoke' or
> 'applyAsDouble') which is the unique method name for the functional type.
yes, it can be done.
But it's not because it can be done that it should be done, as usual the
devil is in the details :)
The rules to choose the applicable methods when doing the overload
resolution only deals with methods,
so if someone introduces a new method in a class, it's easy to see if it
will create a compatibility issue or not,
so it's something which is manageable. Note that the compatibility can
be broken without boxing and varargs
just by inserting an overload that is more specific than an existing one.
Juggling between scopes in backward order is not something 'like this'.
Trying to first lookup in the method scope which is more global to then
fallback to the local variable scope (which is more local)
has the nasty property that you have no way to know if introducing a
method will or not break the source compatibility.
Having a lambda typed by a jli.MethodHandle or a jlr.Method is another
> — John
More information about the lambda-dev