State of the Lambda

[Reinier Zwitserloot]

With static imports you can do something rather similar based around the
current proposal:

from(persons).select({p -> p.getName()}, {p -> p.getAge()});

from would be something like:

public static <T> Selector<T> from(Collection<T> c) { ... }

and select would be:

public interface Transformer<A, R> { R transform(A in); }
public class Selector<T> {
    public List<Object> select(Transformer<T>... transformers) {
        ...
    }
}

By moving the 'from' to the front, type inference on the list can eliminate
the need for a mandatory mention of the "Person" type; the compiler can
figure out that the select method can only take a varargs list of
Transformer<Person> instances, which means all those lambda expressions will
be fitted to that SAM type, which results in the compiler being able to
infer both Transformer<Person> itself as well as the parameter type
(Person).

 --Reinier Zwitserloot



On Thu, Jul 8, 2010 at 9:39 PM, John Nilsson <john at milsson.nu> wrote:

> All in all I like the approach you are taking, do agree with the -1 on
> yield though.
>
> One question wrt method references: do you intend to support "unbound"
> references to to instance methods? The use case being a shorter syntax
> to define expression lists in query like expression. I.e. With the
> current proposal I guess I could have an expression like this:
>
>    select<Person>({ p -> p.getName() }, { p -> p.getAge() }).from(persons)
>
> A use case I imagine won't be to uncommon. F.ex. in our system we have
> resorted to strings and reflection to select properties from objects.
>
>    select("name","age").from(persons)
>
> By "unbound" method reference I thus mean any syntactic sugar that
> shortens the syntactic distance between the two expressions.
>
> BR,
> John
>
>