Java 8方法签名中的不一致 [英] Inconsistency in Java 8 method signatures

问题描述

Java 8为我们提供了具有很长签名的新方法，如下所示:

Java 8 has given us new methods with really long signatures like this:

static <T,K,U,M extends Map<K,U>> Collector<T,?,M> toMap(
    Function<? super T,? extends K> keyMapper, 
    Function<? super T,? extends U> valueMapper, 
    BinaryOperator<U> mergeFunction, Supplier<M> mapSupplier)

对此我感到奇怪的是，通配符已用于确保前两个参数尽可能通用，而第三个参数只是一个BinaryOperator<U>.如果它们一致，那么肯定是BiFunction<? super U,? super U,? extends U>?.我想念什么吗?是有充分的理由吗?还是他们只是想避免使本已可怕的签名变得更糟?

What I find odd about this is that wildcards have been used to ensure that the first two parameters are as general as possible, yet the third parameter is just a BinaryOperator<U>. If they'd been consistent, surely it would be a BiFunction<? super U,? super U,? extends U>?. Am I missing something? Is there a good reason for this, or did they just want to avoid making an already horrendous signature even worse?

修改

我了解PECS，并且了解以下原理:应将mergeFunction视为采用两个U并取回U的方式.但是，能够具有可以以许多不同方式重用的对象将是有用的.例如:

I understand PECS, and I understand the principle that mergeFunction should be thought of as a way of taking two Us and getting back a U. However it would be useful to be able to have an object that could be reused in many different ways. For example:

static final BiFunction<Number, Number, Double> 
        MULTIPLY_DOUBLES = (a, b) -> a.doubleValue() * b.doubleValue();

很明显，这不是BinaryOperator<Double>，但是可以将它作为处理.如果可以根据上下文将MULTIPLY_DOUBLES用作 ，BiFunction<Number, Number, Double>和BinaryOperator<Double>，那将是很棒的.特别是，您可以简单地传递MULTIPLY_DOUBLES来表示您希望使用乘法来减少double的负载.但是，toMap的签名(以及Java 8中的其他新方法)不允许这种灵活性.

Obviously this is not a BinaryOperator<Double>, but it could be treated as one. It would be great if you could use MULTIPLY_DOUBLES as both a BiFunction<Number, Number, Double> and a BinaryOperator<Double>, depending on the context. In particular, you could simply pass MULTIPLY_DOUBLES to indicate that you want a load of doubles to be reduced using multiplication. However the signature for toMap (and other new methods in Java 8) does not allow for this kind of flexibility.

推荐答案

您正确的是 merge 操作的功能签名( reduce 也是如此)不需要类似BinaryOperator的界面.

You are right in that the functional signature of the merge operation (the same applies to reduce) does not require an interface like BinaryOperator.

不仅可以通过toMap收集器的mergeFunction最终位于

This can not only be illustrated by the fact that the mergeFunction of the toMap collector will end up at Map.merge which accepts a BiFunction<? super V,? super V,? extends V>; you can also convert such a BiFunction to the required BinaryOperator:

BiFunction<Number, Number, Double> 
    MULTIPLY_DOUBLES = (a, b) -> a.doubleValue() * b.doubleValue();
Stream<Double> s = Stream.of(42.0, 0.815);
Optional<Double> n=s.reduce(MULTIPLY_DOUBLES::apply);

或完全通用:

public static <T> Optional<T> reduce(
    Stream<T> s, BiFunction<? super T, ? super T, ? extends T> f) {
    return s.reduce(f::apply);
}

---

创建BinaryOperator和UnaryOperator的最可能原因是与这些没有原始超级接口的函数的原始类型版本保持对称.

---

The most likely reason for creating BinaryOperator and UnaryOperator is to have symmetry with the primitive type versions of these functions which don’t have such a super interface.

在这方面，方法 是一致的

In this regard, the methods are consistent

• Stream.reduce(BinaryOperator<T>)
• IntStream.reduce(IntBinaryOperator)
• DoubleStream.reduce(DoubleBinaryOperator)
• LongStream.reduce(LongBinaryOperator)

• Stream.reduce(BinaryOperator<T>)
• IntStream.reduce(IntBinaryOperator)
• DoubleStream.reduce(DoubleBinaryOperator)
• LongStream.reduce(LongBinaryOperator)

或

• Arrays.parallelPrefix(T[] array, BinaryOperator<T> op)
• Arrays.parallelPrefix(int[] array, IntBinaryOperator op)
• Arrays.parallelPrefix(double[] array, DoubleBinaryOperator op)
• Arrays.parallelPrefix(long[] array, LongBinaryOperator op)

• Arrays.parallelPrefix(T[] array, BinaryOperator<T> op)
• Arrays.parallelPrefix(int[] array, IntBinaryOperator op)
• Arrays.parallelPrefix(double[] array, DoubleBinaryOperator op)
• Arrays.parallelPrefix(long[] array, LongBinaryOperator op)

这篇关于Java 8方法签名中的不一致的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！