如果我理解正确的话,Integer[]
是 Object[]
的子类型。例如你可以做
Object[] objs = new Integer[] { 1, 2, 3 };
在使用 var-args 时我意识到,似乎编译器“过度近似”了数组类型,没有明显的原因。
例如下面的程序,打印123
123
。如果它打印 123
6
是不是更有意义/更精确?
class Test {
public static Object combine(Object... objs) {
if (objs instanceof Integer[]) {
int sum = 0;
for (Integer i : (Integer[]) objs)
sum += i;
return sum;
} else {
String concat = "";
for (Object o : objs)
concat += o;
return concat;
}
}
public static void main(String[] args) {
System.out.println(combine("1", "2", "3")); // prints 123
System.out.println(combine(1, 2, 3)); // prints 123
}
}
我想我的问题可以总结为:如果 JLS 被定义为传递 T[]
作为参数,是否会出现任何矛盾/问题,其中 T
是给定所有参数类型的最小上限?
编辑:我意识到,在这种特殊情况下,我可以重载 combine
方法来获取 Integer[]
( ideone demo)。尽管如此,为什么选择这种设计的问题仍然存在。
最佳答案
关于这个具体问题:
Would any contradiction / problem arise if the JLS was defined to pass T[] as argument, where T was the least upper bound of the types of all arguments given?
是的,因为数组不是只读的;它是可写的:
package com.example.test;
import java.util.Arrays;
public class Varargs3 {
public static Object[] changeLastArgument(Object... objs) {
if (objs.length > 0)
objs[objs.length-1] = "Pow!";
return objs;
}
public static void main(String[] args) {
System.out.println(
Arrays.toString(changeLastArgument(1,2,3))
);
}
}
打印
[1, 2, Pow!]
如果 JLS 是按照您要求的方式定义的(例如,对于 foo(T... args)
,如果您调用 foo(a,b,c)
,则编译器会构造一个类型 a、b、c 的最小上限数组),那么这种情况将允许运行时错误:调用 changeLastArgument(1,2,3)
将创建一个类型为 Integer[]
的数组,但是 changeLastArgument()
方法将尝试分配 "Pow!"
到最后一个元素,你会得到一个运行时错误。
changeLastArgument()
的声明正在指定其输入类型,因此它应该能够假设其输入参数确实是一个 Object[]
而不是 Object[]
的子类型,以便它可以安全地修改输入参数。 (这类似于 PECS principle——为了使 List<T>
既安全可读又可写,你不能使用任何像 List<? extends T>
这样的通配符——它是安全可读但不可安全写入的——或者List<? super T>
-- 可安全写入但不可安全读取。)
关于java - 为什么 var-arg 参数的类型是 "over approximated"?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6535394/