State of the Lambda

[John Nilsson]

Somewhat how LINQ does it, isn't it?

Usually we define the projection before there exists a collection to
select from though so I would then have to provide Person.class or
something as argument.

Actually I guess there's some other ways to do this that might make
more sense than specific syntax.

1. With a lambda returning the entire list directly: { Person p ->
select(p.getName(),p.getAge()) }
2. Generate meta data to define the projection:    Query.persons({ p
-> select(p.name,p.age) });

The idea in 2 being that the type of p is a MetaPerson.

BR,
John


On Fri, Jul 9, 2010 at 5:58 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> 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
>>
>
>