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