Re: [問題] Wrapping/Widening + Var-args
※ 引述《bennylu (減肥)》之銘言：
: How about this example
: method(5);
: ..
: void method(int... i) {System.out.print("int...");}
: void method(long... i) {System.out.print("long...");}
: 如果沒會錯意, 那3個步驟只能告訴我哪些method是符合資格的,
: 但並沒有提到當有多個候選人時該如何作選擇, 所以也不會提到ambiguous問題,
: 下面這篇文章和我有一樣的問題
: http://java.itags.org/java-certification/337/
結論先說在前頭，
我的看法跟你連結裡 jesperyoung 所回覆的相同，
這確實是一個 compiler 的 bug。
===
在 JLS 15.12 Method Invocation Expressions 中有詳細的定義:
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.12
在 15.12.2 提到:
If several applicable methods have been identified during one of the three
phases of applicability testing, then the most specific one is chosen.
applicable method 的定義則是:
A method is applicable if it is either applicable by subtyping (§15.12.2.2),
applicable by method invocation conversion (§15.12.2.3),
or it is an applicable variable arity method (§15.12.2.4).
(剛好對應三個階段。)
註: JLS 對這三個階段的定義比較詳細，
我先前貼的直接將 generics method 忽略掉了。
完整定義請參考 15.12.2.2 ~ 15.12.2.4
在做 method resolution 時，會依序測試那三個階段，
如果在任何一個階段中，
只有一個 the most specific method，就可以選定它。
如果有多個 the most specific method，便是 ambiguous。
若一個都沒有，則繼續下一個階段。
剩下最後一個問題是，如何找出 most specific method?
當有兩個 method m1, m2 皆為 applicable 時，
並且 m1 的每一個 parameter 都是 m2 parameter 的 subtype 時，
我們稱 m1 is more specific than m2。
註: 上面為了方便說明，我忽略了 generics 和 varargs，
正確定義請參考 15.12.2.5
讓我直接舉兩個例子:
void foo(int a, long b){} // m1
void foo(long a, int b){} // m2
當我呼叫 foo 並傳入兩個 int 時，如 foo(0,1)，
m1, m2 之間並不存在 more specific 關係，
因此 m1, m2 都是 most specific method，造成 ambiguous。
第二個例子:
void foo(float a, long b){} // m1
void foo(long a, int b){} // m2
在這個例子中，因為 m2 的兩個參數都可以 implicitly casting 成 m1 的參數，
因此 m2 is more specific method than m1，
所以 resolution 的結果會是選擇 m2。
註: 對於 primitive type 來說，subtype 的定義為:
"被箭頭指向的 type" 是 "指向它人的 type" 的 subtype，
即 int 是 byte, short, char 的 subtype。
詳細可參考 4.10.1。
8-bits 16-bits 32-bits 64-bits
-----------------------------------------------
byte ──→ short ─┬→ int ──→ long
(signed) │ ┌────┘
char ─┘ ↓
(unsigned) float ─→ double
結論就是，根據 JLS 的定義，
void method(int... i) {System.out.print("int...");}
void method(long... i) {System.out.print("long...");}
method(5) 應該會執行參數為 int... 的 method，
但 compiler 卻沒有這樣做，並且認為這是 ambiguous。
而因為這個 bug 的 priority 是 Vary Low，
所以拖了近六年至今還沒被處理掉....XD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.115.134.17
※ 編輯: tkcn 來自: 59.115.134.17 (09/08 22:20)
→
09/08 22:31, , 1F
09/08 22:31, 1F
→
09/08 22:47, , 2F
09/08 22:47, 2F
→
09/08 22:49, , 3F
09/08 22:49, 3F
→
09/08 22:51, , 4F
09/08 22:51, 4F
→
09/08 22:55, , 5F
09/08 22:55, 5F
→
09/08 23:17, , 6F
09/08 23:17, 6F
→
09/08 23:18, , 7F
09/08 23:18, 7F
→
09/08 23:21, , 8F
09/08 23:21, 8F
→
09/08 23:38, , 9F
09/08 23:38, 9F
→
09/08 23:43, , 10F
09/08 23:43, 10F
→
09/09 01:02, , 11F
09/09 01:02, 11F
→
09/09 01:06, , 12F
09/09 01:06, 12F
→
09/09 01:07, , 13F
09/09 01:07, 13F
前面推文的時後完全忘記我可以回來修文章 Orz
我要說的範圍都在 15.12.2.5 之內，
Integer 比 long more specific 這點應該毫無疑問(非 varargs 情況下)，
這個部份在 phase 2 就會完成，根據 15.12.2.3:
For 1<=i<=n, the type of ei, Ai, can be converted by
method invocation conversion (§5.3) to Si.
節錄 5.3:
Method invocation contexts allow the use of one of the following:
a boxing conversion (§5.1.7) optionally followed by widening reference
conversion
an unboxing conversion (§5.1.8) optionally followed by a widening
primitive conversion.
而根據 phase 3 定義，並沒有任何違反上述規則的條件。
※ 編輯: tkcn 來自: 140.122.183.199 (09/09 09:20)
推
09/09 11:52, , 14F
09/09 11:52, 14F
→
09/09 11:54, , 15F
09/09 11:54, 15F
討論串 (同標題文章)