为什么Map.compute（）采用BiFunction [英] Why does Map.compute() take a BiFunction

问题描述

我不明白为什么 Map.compute（）和 Map.computeIfPresent（） take BiFunction 参数以及 Map.computeIfAbsent（） a 函数：

V计算（K key，BiFunction<？super K，？super V，？extends V> remappingFunction） code>
V computeIfPresent（K key，BiFunction<？super K，？super V，？extends V> remappingFunction）
V computeIfAbsent（K key，Function<？super K， ？扩展V> mappingFunction）

$ b $我希望一个普通的 功能及LT ;?超V，？扩展V> ，将旧值映射到新值， 供应商<？为新值扩展V> 。呼叫者已经拥有密钥（第一个参数），因此该功能或供应商已经可以使用它。我发现的所有例子都不用键。我想到的原因是：

• 密钥必须（有效） final - 这很容易管理


• 有一些花哨的易于使用的方法参考

但是我不相信这些设计是可行的。你有什么想法吗？

解决方案

你可能会看到 computeIfPresent 作为单个 <$ c的真实吊坠$ c> replaceAll ，而后者需要将键作为参数，但是支持与两个操作的输入相同的功能是很自然的，API是一致这里：它总是提供关键作为参数的参数。

通常，提供密钥可以提高现有函数的可重用性，无论是方法 BiFunction 接口的引用或普通类实现（即非lambda）。但是这种可重用性也可能会影响现有JRE实现的lambda表达式：

如这里所述，捕获来自周围环境的值的lambda表达式可能会在每个捕获进程的各个实例中结束，而使用其参数的lambda表达式（非捕获lambdas）将最终作为单例实例。相反，使用另外没有使用的参数没有性能影响。因此，接收密钥作为参数也是理想的。

I don't understand why Map.compute() and Map.computeIfPresent() take BiFunction parameters as well as Map.computeIfAbsent() a Function:

V compute(K key, BiFunction<? super K,? super V,? extends V> remappingFunction) V computeIfPresent(K key, BiFunction<? super K,? super V,? extends V> remappingFunction) V computeIfAbsent(K key, Function<? super K,? extends V> mappingFunction)

I'd expect an ordinary Function<? super V, ? extends V>, mapping the old value to a new value, resp. a Supplier<? extends V> for the new value. The caller already has the key (first argument) so the function or the supplier can already make use of it. All examples I found don't use the key. The reasons that come to my mind:

• the key must be (effectively) final -- that's easy to manage
• there are some fancy easy-to-use method references

But I don't believe these are viable reasons for this design. Do you have any ideas?

解决方案

You may see computeIfPresent as the single-entry pendant of replaceAll whereas the latter requires the key as a parameter, but it’s natural to support the same function as input to both operations and the API is consistent here: it always provides the key as parameter to the function.

Generally, providing the key raises the reusability of existing functions, be it method references or ordinary class implementations (i.e. non-lambda) of the BiFunction interface. But this reusability may also affect the performance of lambda expressions given the existing JRE implementation:

As described here, lambda expressions capturing values from the surrounding context may end up in individual instances for each capturing process, whereas lambda expressions only using their parameters (non-capturing lambdas) will end up as a singleton instance. In contrast, having an otherwise unused parameter has no performance impact. So receiving the key as a parameter is preferable for that reason as well.

这篇关于为什么Map.compute（）采用BiFunction的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！