※ 引述《sbrhsieh (sbr)》之銘言： : : interface A<+T> { : : public T get(); // OK : : } : : interface C<-T> { : : public void set(T t); // OK : : } : : interface E<T> { : : public T get(); // OK : : public void set(T t); // OK : : } : 我認為 generic type 大部分會是上述的 interface E 這種型態居多，這種類型 : 的 generic type 在 scala 裡只能定義為 non-variant subtyping，那麼用上此 : feature 的機會不多。 我覺得因為 Java type parameter 是 invariant 的, 所以看不出 A 和 C 的好處. 舉個使用 covariant type 的例子 (pseudo java): interface Set<+T> { public T get(); } class Algorithm { public static Number findMax(Set<Number> s) { .... } } // 下面都可以用, 因為 type parameter 是 covariant Set<Integer> si = /* new ... */; Integer i = Algorithm.findMax(si); Set<Double> sd = /* new ... */; Double d =Algorithm.findMax(sd); 實務上常常會有很多東西可以被 model 成 immutable object, 只能讀取不能修改, 如果使用 generics 來設計這些東西, parameterized type 之間能有繼承的關係, 譬如可以設計成 IPod 繼承 Product 則 Parts<IPod> 繼承 Parts<Product>, 我覺得很多時候會蠻直覺的. : 第二，我認為不應該是由 generic type 來決定 subtyping variance，而是由 : client code 來決定。 : ,,, : 如果一個 Java programmer 沒有對 wildcard/bounded wildcard 有足夠的觀念， : 那麼即使把 scala Variance Annotations 加入 Java PL，對他們不會帶來多大的 : 好處(因為 Variable 這種類型的 generic type 佔大多數)。 這就很難說哪樣比較好了... 兩種方法雖然表面上看起來都可以做到一樣的事, 譬如我上面舉的例子您可能說宣告 findMax(Set<? extends Number> a) 就好了, 但這兩種方法有一個微妙的差別: Java 的方法表示宣告 variance 的責任落在使用型別的人, 而 Scala 的方法表示宣告 variance 的責任落在設計型別的人. 我本來以為 Java 的方法比較保守, 但後來仔細看了 Scala 後, 反而覺得 Java 的方法比較亂, 雖然可以活用, 但這樣活用的代價是型別會被允許處在一個 語意不正確的狀態. 我來舉個例子: interface A<T> { public T get(); public void set(T t); } static void func(A<? extends Number> a) { Number n = a.get(); // OK a.set(n); // compile time error a.set(123); // compile time error a.set(new Object()); // compile time error a.set(null); // only this is OK } 上面那個 func() 裡面, 如果沒有前三個 set() 呼叫, 是可以 compile 沒問題的. 但是 T 用在 parameter type 的時候根本不該允許 <? extends Number> 這種 covariant binding, 也就是說, Java compiler 允許 A 處在一個不正確 的狀態, 讓 A.set() 變成完全無用, 只能放 null 進去. 只允許 s.set(null) 從語意上就變得說不通了, 原先的 A<T> 可以 a.set(a.get()) 為什麼 進到 func() 裡後不能 a.set(a.get())? 是因為 A 裡的 T 只該允許 invariant. Scala 的方法讓整個 type polymorphism 變得很一致, 即使有 type parameter 還是可以有繼承的關係. Type parameter variance 的能力跟本來就 T 在型別裡面 使用的位置有直接的關係, 所以宣告 variance 的責任落在設計型別的人身上, 感覺既合理又清楚. 如此一來, 使用型別的人沒有辦法以錯誤的方法使用它, 所以上面的例子用 Scala 的方法來寫的話, 設計 A 的人當初如果宣告 A<T>, 是 invariant, 則沒有變成 covariant/contravariant 的機會: interface A<T> { .... } void func(A<Number> a) { ... } A<Integer> i = /* new something */ func(i); // compile time error A<Object> o = /* new something */ func(o); // compile time error A<Number> n = /* new something */ func(n); // OK 如果需要 covariant 或是 invariant, 當初設計 A 的人就要設計一個是可以允許 +T 或是 -T 的介面, 將來才可以這樣用: interface A<+T> { .... } void func(A<Number> a) { ... } A<Integer> i = /* new something */ func(i); // OK A<Object> o = /* new something */ func(o); // compile time error A<Number> n = /* new something */ func(n); // OK 在使用型別的地方不需要用 <? extends X> 這種東西, 因為這已經定義在 A 裡了, 型別不會像 Java 那樣處在不正確的狀態. 習慣 Java 的人會說 Java 用法比較靈活, 但我自己覺得 Scala 的 variant 方法是往前更進了一步, 語意也更乾淨漂亮. (哈, 語意而已... Scala 的語法我就很難習慣了... Java 中毒太深 :P ) --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 60.251.144.115