※ 引述《macbuntu (邀怪)》之铭言： : Scala 的 compiler 就会把上面红色的地方标成错误而不会 compile 成功, : 原因是 Scala 会根据型别出现的位置来决定该位置所能允许的 variant 种类, : 所以像 function argument type 是 contravariant 而 return type 是 covariant : 这类的规则直接定义成语言的一部分, 再将 programmer 宣告的 +/- variant 方式 : 跟这些位置作比对, 符合才放行, 从根本上解决了 variant 跟 OO 的冲突问题. : 觉得这种方法挺漂亮的, 其实可以加到 Java 的语法里又不会造成冲突. : 以现在的 Java 来说: : interface A<T> { : public T get(); : } : class B { : static void func(A<Object> a) { .... } : } : A<String> obj = /* new something */; : B.func(obj); // compile time error, A<String> is not an A<Object> : 这里 Java compiler 不允许, 但是仔细看 A<T> 的 T 其实只用在 return type, : 把 A<String> 当作 A<Object> 使用一点问题也没有. 如果把 Scala 的设计加进去: : interface A<+T> { : public T get(); // OK : } : interface B<+T> { : public T get(); // OK : public void set(T t); // compile time error : } : interface C<-T> { : public void set(T t); // OK : } : interface D<-T> { : public T get(); // compile time error : public void set(T t); // OK : } : interface E<T> { : public T get(); // OK : public void set(T t); // OK : } : 靠 compiler 来检查所有定义为 +T (covariant) 的型别只能用在 return type, : 而所有 -T (contravariant) 的型别只能用在 arguments type, : 如果同时用在两个地方, 或是 public field type, 就一定得指定成 T (invariant), : 这样就皆大欢喜了. : [略] : 印象中现在 Java 1.5 generics type 的设计就是出自於设计 Scala 的同一人? : 不知他当时没把这个放入 Java 中是有什麽原因? 还是当初还没有这个点子... 我没有什麽 scala programming 的经验，我想请教 scala 中 generic type 定义时使用的 Variance Annotations 实际上能带来什麽好处？ 你觉得如果把这个 feature 加进 Java PL 是个好事，可否请你说说这个 feature 在实际 programming 上带来最大的好处是什麽？你一定有你自己的想法，你才会 认为如果 Java 也加入这个 feature 是好的。 我认为 generic type 大部分会是上述的 interface E 这种型态居多，这种类型 的 generic type 在 scala 里只能定义为 non-variant subtyping，那麽用上此 feature 的机会不多。 第二，我认为不应该是由 generic type 来决定 subtyping variance，而是由 client code 来决定。 假设今天有一个如下的 interface: // Java code public interface Variable<T> { public T getValue(); public void setValue(T val); } 这个 class 以 scala 来实做也只能定义成 non-variant subtyping。 今天有一个 client code 需要使用到 Variable instance，他需要做的是只是 把 Variable value 输出到 stdout，那麽他只需要 Variable value 至少是个 Object 即可。 // Java code public class Interpreter { public void dump(Variable<? extends Object> var) { System.out.println(var.getValue()); } } 这种情况下，client 只使用到 Variable - getValue method，所以可以容许 var 变数是 co-variant subtyping；如果有另一个功能需要使用到的只有 Variable - setValue method，那麽他可以自行决定容许 contra-variant subtyping。比如现在要实做一个 assign 某个 String value 成 Variable value， 若直接写成这样: // Java code public void assign(Variable<String> var, String val) { var.setValue(val); } 就会发生如同你描述的现象：无法将 String value assign 给 Variable<Object>。 但实际上是设计 assign 操作的人应该要想到，String value 应该可以 assign 给 type parameter lower bound 在 String 的 Variable instance，而写成 ： // Java code public void assign(Variable<? super String> var, String val) { var.setValue(val); } 或是更一般化： public <V> void assign(Variable<? super V> var, V val) { var.setValue(val); } ＊ 这在 scala 中也是要采用类似的作法 如果一个 Java programmer 没有对 wildcard/bounded wildcard 有足够的观念， 那麽即使把 scala Variance Annotations 加入 Java PL，对他们不会带来多大的 好处(因为 Variable 这种类型的 generic type 占大多数)。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.173.129.21