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