※ 引述《sbrhsieh (sbr)》之銘言： : 你能不能把一個 generic class/interface 宣告為 covariant or contravariant : subtyping 是決定在此 class/interface 的規格上，不是在於你的意圖。而 client : code 要設計成 convariant usage or contravariant usage，是決定在 client code : 的意圖，而不是在於 A 是 A<+T>, A<-T> or A<T>。那為甚麼還需要 variance : annotation？ 可以直接從 class/interface 的規格來決定 variance 阿, 這就是我之前提的透過 implicit semantic rule 直接把 Scala 的想法放進 Java 裡 而不加 +/-. 但是 explicit annotation 的好處就如同 @Override 這種東西, 指明意圖後可以讓 compiler 幫我們檢查錯誤. 您前面提到如果有一天 A<+T> 裡面有人加上 set(T t) 這個 method, 變成被逼得只能改成 A<T>, 然後一堆現有的程式變得不能 compile... 這點我倒完全沒想到, 感覺還真是蠻大的缺點... 雖然從嚴謹的角度看, 加上 set(T t) 以後 A 就不是 immutable, 本來就不該繼續允許 covariant T, 但是實務上, Java 的方法能讓現有程式不受影響, 這種妥協感覺蠻值得的. 搞不好這就是 Java 選擇現有設計的原因? 這種東西還真的沒有對錯, 尤其在設計語言的時候, 中間要妥協的灰色地帶很多, Java 的選擇使得 generics type 互相沒有繼承關係, 我覺得有時在語意上表達 就沒那麼直覺, 新手就常常會試著要把 Set<String> 當成 Set<Object> 來用... 但所謂 "直覺" 真是超主觀的. 回到我自己的觀點, 我還是覺得一個 strongly-typed language 會出現 前面說的 set(null) 的狀況, 算是語言設計上的瑕疵. 雖然說 programmer 不要去呼叫它就好了, 但一個好的設計不該出現這種狀態. 從語言使用者的角度, 只要他有辦法用這個語言寫他想要的東西, 這個語言就夠好了. 但從語言設計者的角度, 就是需要在意這種小瑕疵, 才有機會設計更好的語言. 如果能有更好的方法, 讓 generics type 互相有繼承關係, 又可以沒有上面說的 A<+T> 變成 A<T> 的缺陷, 就太好了. --

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