※ 引述《macbuntu (邀怪)》之銘言： : ※ 引述《godfat (godfat 真常)》之銘言： : : 我試了一下 javac, 單純的 func(new X()) 和 func(new Y()) 也是 ambiguous. : : 這個意思不就是除了 void 以外，所有 exp 的 result type 都必須是集合？ : : 不過似乎只需要針對有 overload 的 function 上的 argument 上做這樣的 : : 集合檢查就好？ : 如果沒有 a ? b : c 這種東西, 不用集合就可以檢查了... : new X() 的型別就是唯一的 X, 所以呼叫 func(new X()) 只要一一比對 : func(A), func(int)... 這些名稱跟 parameter 個數符合的 methods, : 用類似 Type.isAssignbleFrom(X) 的方法比對 formal paramter type, : 很快在 linear time 就可以找得到一群 "compatible" methods, : 然後再用另一個演算法看看 "most specific" method 是不是唯一, : 如果唯一就 OK, 否則 ambiguous. 這完全就是 Java compiler 的 method resolution algorithm : : 而 exp0 ? exp1 : exp2 的 result type 則會是 exp1 的 result type : : 與 exp2 的 result type 的交集。最後再跟 function argument 做交集， : : 結果超過一個以上就是 ambiguous. 其他狀況可能不需要這麼麻煩？ : 用集合就變超麻煩的說, 假設有兩個 parameter, 每個各有兩種可能, : 而且那兩個型別互相沒繼承關係, 類似前一篇說的 A, N1, N2 之間: : func( { a,b }, { c,d } ); : 那不就變成要找 compatible methods 的階段就需要測試: : func( a, c ); : func( a, d ); : func( b, c ); : func( b, d ); : 這四種可能? 這複雜度是 exponentional 的耶, 就為了個區區 a ? b : c 囧... : 如果真的要用集合來找, 應該會有什麼聰明的演算法吧? Java Spec. ed 1 & 2 這個 ? : 都是不合法的 -- then part 和 else part 都是 reference type 的時候要不 identical, 要不 assignable. ed 3 裡允許了, 做法我也看不下去, 但是順著 generic 走其實沒那麼復雜: new X() has type: X & N1 & N2 new Y() has type: Y & N1 & N2 這裡的 & 相當於 generic type variable constraint, N1 分別是由 X 和 Y 的 super class implement 的. 在 unify 兩個的時候 class part 取 least upper bound, interfaces 取教交集 ==> b ? new X() : new Y() has type: A & N1 & N2 然後再去 method resolution, 這步沒那麼難, 一樣把名字和 parameter 數目都對的拿出來, 每一個 parameter 跟 class & interface1 & interface2 ... 比較, 可以的留下, 然後再一樣找 most specific method 在這個例子裡兩個 func 都可以 -- 這個 type 是 A 也有 implement N2 但是 A 和 N2 沒有 assignment 關係, 於是可能性不唯一, report error. 話說越寫越覺得跟我想做但是做不下去的 contraint existential types 很像 XD -- A man may die, countries may rise and fall, but an idea lives on. - John F. Kennedy --

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