※ 引述《macbuntu (邀怪)》之銘言： : : 第二，我認為不應該是由 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. 我覺得你沒有看懂我的意思，你這樣子的說法有點兒倒因為果的味道(請不要認為 這是不友善的用詞)。 我說應該由 client code 來決定 subtyping variance，意思是說當上頭的 func 因為 它只需要 a.get() 能夠獲得(至少是) Number instance 時(根本不會用到 A::set method)，設計者就可以把 formal parater a 宣告為 A<? extends Number> type。 你不能反過來說，A<? extends Number> 出現在這個情況下，反而把 a 變成無法使用 set method，你懂我的意思嗎？ 如果上述的 func 的實作是包括有 compile error 那幾個 statement，那麼你就只能 把 formal parameter 宣告為 A<Number>，因為你需要它至少能產生 Number instance 又要至多能 consume/handle Number instance，這兩者的交集只有 A<Number> 這種 instance。 如果你把這個例子改成 scala 來作，你會發現你在實作上會跟 Java 幾乎一樣， 你沒有其他的選擇。 : 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 Java generics 是透過編譯器在編譯期的檢查來作出 type 上的限制，並沒有 runtime 上的強制性，scala 建構在 JVM 上，其 generic type 的設計跟 Java 相似 也是在編譯期檢查，建議儘量不要往限制 client code's capability 的方向去思考 Java/scala generics 的設計。 : 如果需要 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 ) 這就回到我前一篇的提到的第一點，實際上可以去設計出 A<+T> A<-T> 的比例有 多少？ 另外，試想如果 interface A<+T> 的多個 client code 類似於 static void func(A<Number> a) { Number value = a.get(); System.out.println(value.doubleValue()); } 設計者希望 func 能夠處理 A<Integer>, A<Double> 等等 instance，由於 interface A 是個 A<+T>，於是就把 a 宣告為 A<Number>，此時行的通。 (這個 scenario 就是你前一篇一開頭提到的好處) 有一天 interface A 的設計者替 A 增加了一個操作： public void set(T t); 導致 A 只能夠修改為 A<T>，這時候那些 client code 就必須跟著改，但是依照 client code 使用 A<Number> instance 的方式(pure covarinat)，應該是即使 interface A 變成 non-variant，還是要能正確處理 A<Integer>, A<Double> 等等 的 instance。那麼為了不被 interface 變更的影響，是不是一開始我就把 func 定義成 static void func(A<? extends Number> a) { Number value = a.get(); System.out.println(value.doubleValue()); } 還比較好，反正我使用 a 的方式就是我只要 a.get() 至少是得到 Number 就好，我 不在乎 interface A 到底是設計成 covariant, contravariant 還是 non-variant subtyping。 反過來說，如果 func 使用 formal parameter a 的方式就是 a.get() 至少要是 Number instance，同時至多會丟進 Number instance 給 a.set method，那麼不管 是 Java 還是 scala，你的做法會是一樣的(只能把 a 宣告為 A<Number>)。 所以我不覺得 scala 有 Variance Annotation 是好事。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.173.129.21 ※ 編輯: sbrhsieh 來自: 218.173.129.21 (03/18 02:07) ※ 編輯: sbrhsieh 來自: 218.173.129.21 (03/18 19:12)