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