Bitten by the lambda parameter name
forax at univ-mlv.fr
Tue Jul 16 14:59:27 PDT 2013
On 07/16/2013 10:20 PM, Dan Smith wrote:
> On Jul 16, 2013, at 9:20 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> On 07/16/2013 05:05 PM, Maurizio Cimadamore wrote:
>>> On 16/07/13 16:00, Peter Levart wrote:
>>>> Perhaps here, an overloaded Map.computeIfAbsent that takes a Supplier
>>>> instead of Function would be handy. Even when you need the key to
>>>> construct new value, it is usually ready in some effectively-final
>>>> variable in the scope. And when you don't need the key, a constructor
>>>> reference could be applied like:
>>>> partySetMap.computeIfAbsent(kind, HashSet::new).add(...);
>>> I think the underlying problem to this discussion might be that there
>>> are places (and computeIfAbsent seems to be one of them) where the
>>> lambdi-fication of the library took a somewhat convoluted path, in
>>> which the 'same' variables needs to be supplied multiple times in
>>> order to keep the chain happy (which then turns out to be problematic
>>> because of scoping rules).
>> There is a big difference, if you provide the key as parameter the
>> lambda will be a constant so the cost of using it is 0
>> (if you forget the initialization cost), if you don't provide the key as
>> parameter, you will need to capture it and in that case, the runtime
>> will create a fresh lambda for each call.
> So this amounts to a language feature request to facilitate a performance optimization. You'd like to avoid capture by using a pattern that relies on re-declaring variables for identical values, because capture is less efficient. Thus, you wish the language were more friendly to re-declarations.
> In such situations, it's appropriate to ask: is this the tail wagging the dog? Capture is the _right_ way to express what's going on, even if it's less performant. Right?
> I wonder if the efficiency problem will be optimized away someday. Maybe with value types, the VM could avoid boxing up the capture variables with the underlying function?
you take one example, here computeIfAbsent and try to find a
generalization from it.
I've just explained to Maurizio, why computeIfAbsent uses a lambda with
And yes maybe someday, some (not all) fat lambdas will be optimized but
someday is not today and not tomorrow too.
Now, computeIfAbsent is not the only case where the compiler bark for no
refactoring some code for a lab that uses reflection to create objects,
I was really happy because I was able to simply write this snippet,
StringBuilder builder = createText(StringBuilder.class, builder ->
too magic too be true because it doesn't compile.
More information about the lambda-dev