f(x) syntax sugar in Lambda

[Brian Goetz]

I think, ultimately, this is just discomfort with the committment to functional interfaces instead of function types, and an attempt to backpedal towards a wishy-washy middle ground.  I don't see this as offering a compelling enough benefit.  

On Feb 10, 2012, at 3:42 AM, 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? 
> 
> 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.
>