Bitten by the lambda parameter name
forax at univ-mlv.fr
Mon Jul 15 08:41:18 PDT 2013
On 07/15/2013 05:32 PM, Maurizio Cimadamore wrote:
> On 15/07/13 16:28, Remi Forax wrote:
>> On 07/15/2013 05:13 PM, Maurizio Cimadamore wrote:
>>> On 15/07/13 15:52, Remi Forax wrote:
>>>> This snippet not compile,
>>>> Kind kind = ...
>>>> partySetMap.computeIfAbsent(kind, kind -> new
>>>> Each time I write more than a hundred lines of codes that use some
>>>> I fall into this trap.
>>>> It's very annoying !
>>> Annoying yes - but there is a reason for it? If we provide special
>>> scoping for lambda parameters then we will never be able to add
>>> control abstraction syntax in a nice way; not saying that it's
>>> something we want - but it's good to have option open at least.
>> It's a crystal ball argument, in the future if we do that then ...
>> It usually doesn't work because between now and the future, the way
>> the feature will be introduced will change.
> Well, yes and no - I remember we discussed a lot whether a lambda
> should look (semantically) more like a block or an inner class. We
> decided it should look like the former. This is a consequence of that
> decision. I think that mixing and matching semantics on a by-need
> basis is not a good idea.
What we have discussed was: should the lambda be an object (have an
identity etc) or not ?
A lambda is an anonymous function, neither an anonymous class nor a block.
>> In this peculiar case, if we add control abstraction syntax we will
>> use a different syntax,
>> so it's very annoying for no reason.
More information about the lambda-dev