如果我编写了 ToIntFunction 接口,我想在接口中编码它只是一个返回原始 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 完全分开是否有令人信服的理由?是否有证据表明他们考虑这样做并决定反对?我想类似的问题至少适用于其他一些“特殊”功能接口,如消费者(可能是 Function<T,Void>)和供应商(Function<Void,T>)。
我还没有深入和彻底地考虑过这一切的后果,所以我可能遗漏了一些东西。
如果 ToIntFunction(和其他原始通用函数接口)与 Function 有这种关系,它将允许在需要 Function 参数的地方使用它(想到的是与其他函数的组合,例如调用 myFunction.compose(myIntFunction)或者避免在 API 中编写几个专门的函数时,如上所述的这种自动(取消)装箱实现就足够了)。
这与这个问题非常相似:Why doesn't Java 8's Predicate<T> extend Function<T, Boolean>但我意识到由于语义原因,答案可能有所不同。因此,我正在为这种简单的原始替代函数的情况重新制定问题,其中不能有任何语义,只有原始类型与包装类型,甚至消除了 null 包装对象的可能性。