Updated State of the Lambda

[Yuval Shavit]

Essentially, yes. The lambda dev project does a great job of reducing the
cost of functional interfaces at the instantiation point  -- which, don't
get me wrong, is a really great thing and no small improvement. But the
proposal doesn't do much as far as making it easier at the declaration
point. Framed in terms of inheritance-vs-composition, inheritance is still
more convenient (albeit marginally) for the API designer. If lambdas take
off, we'll have an explosion of pretty-much-identical functional interfaces.

One solution I could imagine would be to ship a set of functional
interfaces that are expected to be common -- but then you firstly get into
the problem of "how common is common enough?" and secondly, this just gets
into the structural typing sphere by shoehorning it into the nominal typing
sphere.

I don't have a good solution, but just seems to me that having a few dozen
interfaces that each define a single method with the same signature is not
ideal.

On Sun, Dec 11, 2011 at 7:57 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Because it just doesn't carry its weight.  The alternate version you
> propose is one token shorter.  That would be adding incremental complexity
> for no incremental benefit.
>
> If I had to guess, I would think what you're really getting at is that it
> is annoying to have to declare them as actual interfaces (and worse, one
> class per file), instead of as a local type alias of sorts in the class
> file that uses it.  Is that what you're getting at?
>
>
>
>  What about defining a new syntax for declaring functional interfaces, so
>> that the interface as well as its implementation can address the
>> vertical problem? Something like:
>>
>>    interface MyComparable<T> = int compareTo(T other);
>>
>>
>> Which would be equivalent to:
>>
>>    interface MyComparable<T> {
>>         int compareTo(T other);
>>    }
>>
>> Apologies if this is also covered ground. I searched for java + lambda
>> [dev] + delegate, since this seems a bit similar to C#'s delegate syntax.
>>
>> On Fri, Dec 9, 2011 at 3:32 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com**>> wrote:
>>
>>    Yes, this is well-covered ground.  What you're asking for is
>>    "function types" (or arrow types, or algebraic function types, or
>>    structural functions types.)  The short answer is "no".
>>
>>    Function types are the "obvious right way" to represent the type of
>>    a lambda, until you realize that they will end up getting
>>    implemented using generics, which means they will be erased.  Erased
>>    function types are the worst of both worlds.
>>
>>    Instead, we use functional interfaces in APIs, and then users can
>>    use named classes, anonymous classes, or lambdas to create instances
>>    of the functional interfaces.
>>
>>
>>
>>    On 12/9/2011 1:44 PM, Yuval Shavit wrote:
>>
>>        By the way -- and I apologize if this has already been covered,
>>        I did
>>        some searching and nothing came up -- is there any thought as to
>>        whether
>>        methods will ever be able to declare lambdas as arguments?
>>          Something like:
>>
>>            public <T> void myFilter(Iterable<? extends T>, (? super T ->
>>            boolean) predicate ) { ... }
>>
>>
>>        This function could then take either a lambda of the same type,
>>        or any
>>        reference typed as a functional interface which could be
>>        expressed as a
>>        corresponding lambda.
>>
>>        Thanks,
>>        Yuval
>>
>>        On Fri, Dec 9, 2011 at 1:28 PM, Brian Goetz
>>        <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com**>
>>        <mailto:brian.goetz at oracle.com
>>
>>        <mailto:brian.goetz at oracle.com**>__>> wrote:
>>
>>            An updated State of the Lambda is available here:
>>
>>        http://cr.openjdk.java.net/~__**briangoetz/lambda/lambda-__**
>> state-4.html<http://cr.openjdk.java.net/~__briangoetz/lambda/lambda-__state-4.html>
>>        <http://cr.openjdk.java.net/~**briangoetz/lambda/lambda-**
>> state-4.html<http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html>
>> >
>>
>>
>>
>>
>>