f(x) syntax sugar in Lambda

[Maurizio Cimadamore]

On 10/02/12 08:42, Spot Al wrote:
> What I want to do is just answer on the question:
> If it is possible to create a functional interface without using the method name, why it needs to mention the method name using the functional interface?
I think the potential ambiguities at the call-site would seriously 
undermine code readability. I think this is one of the cases in which, 
just because you can, it doesn't mean you should ;-)

Moreover, we had some experience with the m.() syntax - the first 
version of the prototype supported it and, well, the reaction hasn't 
been exactly positive [1].

[1] - http://www.infoq.com/news/2010/06/lambda-syntax-debate

Maurizio
>
> The most serious objection against using the f(x) invocation is the separate namespaces for methods/fields.
> In this case just an another syntax which does not mention the method name can be used. For example
> double e = exp.(1);  // or any other better syntax
>
> What about the last case which use the default methods, creating the lambda expression and using it without mentioning the method name are the same things. So
> ------------------------------------------
> interface Exponent {
>      double calculate(double x);
>      void foo() default { ... }
>      void bar() default { ... }
> }
>
> Exponent exp = (x) ->  1 + x + x * x / 2;  // which method is defined?
> double e = exp.(1) // which method is invoked?
>
> In both cases we should care about default methods.
>
> Thanks,
> Alexander.
>
>
> 09.02.2012, 13:46, "Maurizio Cimadamore"<maurizio.cimadamore at oracle.com>:
>> Hi,
>> I think there might be few problems with this approach when unleashed in
>> a more widespread way:
>>
>> *) Java has two separate namespaces for methods/fields - so the
>> following would be ambiguous:
>>
>> Exponent exp = (x) ->  1 + x + x * x / 2;
>> void exp(int x) { ... }
>>
>> exp(3) //?
>>
>> *) The language does not have such a thing as 'type of a lambda' so,
>> there is no way to distinguish between:
>>
>> SAM s = ()->  { ... }
>>
>> and
>>
>> SAM s = new SAM() { ... }
>>
>> This means that your proposal will apply to all expressions whose type E
>> is a functional interface.
>>
>> *) What if E is a method call? You end up with things like:
>>
>> Exponent makeExp() { ... }
>>
>> makeExp()(5);
>>
>> *) If you have a functional interface with default methods:
>>
>> interface Exponent {
>>      double calculate(double x);
>>      void foo() default { ... }
>>      void bar() default { ... }
>> }
>>
>> then the fact that the syntactic sugar will rewire the method call to
>> 'calculate' (as that's the only abstract method in Exponent) might
>> result a bit surprising since there is more than one method available in
>> the functional interface.
>>
>> Maurizio
>>
>> On 09/02/12 07:41, Spot Al wrote:
>>
>>>   Hi,
>>>
>>>   For example if there is an interface
>>>   -----------------------------------------------
>>>     interface Exponent{
>>>         double calculate(double x);
>>>     }
>>>   -----------------------------------------------
>>>
>>>   and I have a lambda expression:
>>>   -----------------------------------------------
>>>   Exponent exp = (x) ->    1 + x + x * x / 2;
>>>   -----------------------------------------------
>>>
>>>   would it be possible to get a value like:
>>>      double e = ep(1);
>>>   instead of
>>>      double e = exp.calculate(1); ?
>>>
>>>   Where exp(1) just a syntax sugar for the exp.calculate(1).
>>>
>>>   So if variable a has a lambda type (interface with one method) than a(val1,.., valN) means a.methodName(val1,.., valN)?
>>>
>>>   Thanks,
>>>   Alexander.