anonymous method call

[Remi Forax]

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 
story.

>
> — John

Rémi