f(x) syntax sugar in Lambda

[Yuval Shavit]

This question seems to me to be orthogonal to lambdas. It would apply just
as well to JDK 7. Basically, the request (if I understand it correctly) is
that if you have a reference whose type is an interface that defines just
one method, you should be able to omit the method name in invoking it.
There's a certain symmetry that establishes with lambdas, sure -- but the
call site doesn't know if the Exponent it got in was defined as a standard
class, anonymous class, lambda, proxy, whatever.

On Fri, Feb 10, 2012 at 7:33 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

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