recursive lambda as a local variable
Sam Pullara
spullara at gmail.com
Wed Sep 11 10:58:51 PDT 2013
It was decided later that it wasn't necessary — should be in the email archives. That state of the lambda is from 2011. It does mean that sometimes you need to use an inner class for things that need to be recursive.
Sam
On Sep 11, 2013, at 10:32 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> State of the Lambda seems to suggest that this can be done for local variables:
>
> http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html
>
>> When a lambda expression appears in any other context, such as a return expression, there is no way for it to refer to itself. The proper approach in such cases is to name the object with a variable declaration and replace the original expression with a variable reference.
>
>
>
>
> On Wed, Sep 11, 2013 at 12:16 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Its not so much "intentional" as a consequence of language rules that
>> predate lambda.
>>
>> In the first example, r is a field; in the second, it is a local. What the
>> first lambda really is shorthand for is:
>>
>> Runnable r = () -> this.r.run();
>>
>> So this lambda captures 'this', whereas the second lambda captures 'r'. The
>> latter runs into definite-assignment issues, but fields are not subject to
>> assignment and flow analysis.
>>
>> Of course, when you use 'this' from the initializer of a field, you are on
>> thin ice.
>>
>>
>> On 9/11/2013 12:37 PM, Zhong Yu wrote:
>>>
>>> This compiles: (b106)
>>>
>>> class Test
>>> {
>>> Runnable r = ()->r.run();
>>> }
>>>
>>> but this doesn't:
>>>
>>> void test()
>>> {
>>> Runnable r = ()->r.run();
>>> }
>>>
>>> is that intentional or a bug?
>>>
>>> Zhong Yu
>>>
>>
>
More information about the lambda-dev
mailing list