※ 引述《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