java-8 - 为什么 Java 8 的 ToIntFunction<T> 不扩展 Function<T, Integer>

Question

如果我编写 ToIntFunction 接口(interface)，我想在接口(interface)中编码这样一个事实，即它只是一个返回原始 int 的函数，如下所示:

@FunctionalInterface
public interface ToIntFunction<T> extends Function<T, Integer> {
    int applyAsInt(T value);

    @Override
    default Integer apply(T value) {
        return Integer.valueOf(applyAsInt(value));
    }
}

我想知道，是否有令人信服的理由让 Java 8 API 设计者选择将原始替代方案与 Function 完全分开？是否有证据表明他们考虑过这样做并决定反对？我想类似的问题至少适用于其他一些“特殊”功能接口(interface)，例如 Consumer(可能是 Function)和 Supplier(Function)。

我还没有非常深入和彻底地思考这一切的后果，所以我可能遗漏了一些东西。

如果 ToIntFunction(和其他原始通用功能接口(interface))与 Function 有这种关系，它将允许人们在需要 Function 参数的地方使用它(想到的是与其他功能的组合，例如调用 myFunction.compose (myIntFunction)或避免在 API 中编写多个专用函数，当上述自动(取消)装箱实现就足够时)。

这与这个问题非常相似:Why doesn't Java 8's Predicate<T> extend Function<T, Boolean>但我已经意识到，由于语义原因，答案可能会有所不同。因此，我正在为这种情况重新制定问题，即函数的简单原始替代方案，其中不能有任何语义，只有原始类型与包装类型，甚至消除了 null 包装对象的可能性。

Answer 1

JDK 8 中的接口(interface)爆炸是 Java 中一个小问题的产物:缺少值类型。

这意味着我们不能将原始类型与泛型一起使用，因此，我们不得不使用包装器类型。

换句话说，这是不可能的:

Function<String, int> myFunction;

但这是:

Function<String, Integer> myFunction;

问题在于装箱/拆箱。由于不断需要为原始值创建包装对象，反之亦然，这可能会变得昂贵并且使处理原始数据类型的算法难以优化。

这解释了为什么 JDK 8 中的接口(interface)呈爆炸式增长，例如 Function 和 IntFunction，后者使用基本类型作为参数。

这在 Lambda Mailing List 中的某个时刻进行了讨论透露专家组正在努力解决这个问题。

lambda 项目的规范负责人 Brian Goetz 在那里写道:

More generally: the philosophy behind having specialized primitive streams (e.g., IntStream) is fraught with nasty tradeoffs. On the one hand, it's lots of ugly code duplication, interface pollution, etc. On the other hand, any kind of arithmetic on boxed ops sucks, and having no story for reducing over ints would be terrible. So we're in a tough corner, and we're trying to not make it worse.

Trick #1 for not making it worse is: we're not doing all eight primitive types. We're doing int, long, and double; all the others could be simulated by these. Arguably we could get rid of int too, but we don't think most Java developers are ready for that. Yes, there will be calls for Character, and the answer is "stick it in an int." (Each specialization is projected to ~100K to the JRE footprint.)

Trick #2 is: we're using primitive streams to expose things that are best done in the primitive domain (sorting, reduction) but not trying to duplicate everything you can do in the boxed domain. For example, there's no IntStream.into(), as Aleksey points out. (If there were, the next question(s) would be "Where is IntCollection? IntArrayList? IntConcurrentSkipListMap?) The intention is many streams may start as reference streams and end up as primitive streams, but not vice versa. That's OK, and that reduces the number of conversions needed (e.g., no overload of map for int -> T, no specialization of Function for int -> T, etc.)

可能，将来当我们得到Support for Value Types时在 Java 中，我们将能够摆脱(或者至少不再需要再使用)这些接口(interface)。

专家组在多个设计问题上苦苦挣扎，而不仅仅是这个。保持向后兼容性的需要、要求或约束使事情变得困难，然后我们还有其他重要条件，如缺少值类型、类型删除和检查异常。如果 Java 有第一个而没有其他两个，那么 JDK 8 的设计就会大不相同。因此，我们都必须明白，这是一个需要权衡取舍的难题，EG 必须在某处划清界限并做出决定。