f(x) syntax sugar in Lambda
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Feb 10 02:35:21 PST 2012
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.
More information about the lambda-dev
mailing list