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