hg: lambda/lambda/langtools: Added basic support for constructor references.

[Rémi Forax]

On 01/18/2011 03:47 PM, Paulo Silveira wrote:
> Hello Thomas
>
> 2011/1/18 Thomas Münz, XDEV Software Corp.<t.muenz at xdev-software.de>:
>> It is fully understandable that Field references (weren't they called "Field literals" once? Or is that another thing?) are not in the scope of project lambda.
>> Still, this shouldn't mean that there is no need for a future feature like that just because they're not closely related to lambdas (it sounded that way, sry if that's a misinterpretation).
> I think most of developers are waiting for Method/Field literals for
> years, even for jlr.Method/Field (not for using them as SAMs). This
> would really help validation frameworks, JPA criterias, and so on. But
> Brian and others are right: if project Lambda tries to embrace this,
> it will take more time, more effort and it is not needed by Lambda
> itself.

There are two ways to view Method/Field literals.
One is to view them as an expression that can be called,
in that case the Method literal is a lambda expression.
The other way is to view it as a kind of DSL, by example for binding
a field to a swing component. In that case, jlr.Method/Field is not the 
solution,
what is needed is Groovy's AST node or C# expression tree.

> But as Alessio, I would vote for them.
>
> bye
>
> Paulo

cheers,
Rémi