string隱式轉(zhuǎn)換的二義性問題
scala標(biāo)準(zhǔn)庫(kù)在Predef對(duì)象中定義了兩個(gè)String的隱式轉(zhuǎn)換：
implicit def augmentString(x: String): StringOps
implicit def wrapString(s: String): WrappedString
而StringOps和WrappedString有一些重復(fù)的方法横腿，如count：
?StringOps中定義了count方法
def count(p: (Char) ? Boolean): Int
Counts the number of elements in the traversable or iterator which satisfy a predicate.
WrappedString也有count方法
def count(p: (Char) ? Boolean): Int
Counts the number of elements in the traversable or iterator which satisfy a predicate.
?兩個(gè)count方法??完全一樣，應(yīng)該存在二義性問題啊败许。試著在REPL中寫了?一?段隱式轉(zhuǎn)換的代碼越平，果然會(huì)提示有二義性：
case class A1(a: Int) {
def guess = a * 10
}
case class A2(a: Int) {
def guess = a * 100
}
implicit def Int2A1(a: Int) = new A1(a)
implicit def Int2A2(a: Int) = new A2(a)
scala> 1.guess
<console>:14: error: type mismatch;
found : Int(1)
required: ?{def guess: ?}
Note that implicit conversions are not applicable because they are ambiguous:
both method Int2A1 of type (a: Int)A1
and method Int2A2 of type (a: Int)A2
are possible conversion functions from Int(1) to ?{def guess: ?}
1.guess
^
<console>:14: error: value guess is not a member of Int
1.guess
但是從上一篇隱式轉(zhuǎn)換的文章可以知道"hello".count不但沒有報(bào)錯(cuò)闸拿，還會(huì)選擇StringOps.count褐桌。?為什么會(huì)這樣呢？
?隱式轉(zhuǎn)換的優(yōu)化級(jí)
在Martin Odersky親自寫的《Programming in Scala(Third Edition)》21.7節(jié)最后有下面這一段說明：
The old implicit conversion to a Scala collection (now named WrappedString) is retained. However, there is a more specific conversion supplied fromString to a new type called StringOps. StringOps has many methods such as reverse, but instead of returning a collection, they return a String. The conversion to StringOps is defined directly in Predef, whereas the conversion to a Scala collection is defined in a new class, LowPriorityImplicits, which is extended by Predef. Whenever a choice exists between these two conversions, the compiler chooses the conversion to StringOps, because it's defined in a subclass of the class where the other conversion is defined.
簡(jiǎn)而言之饼记，編譯器之所以會(huì)選擇StringOps而不是WrappedString香伴，是因?yàn)?code>StringOps更特化(more specific)。為什么說StringOps更特化呢具则？讓?我們先看看Predef對(duì)象的?繼承關(guān)系：
object Predef extends LowPriorityImplicits with DeprecatedPredef {
/* ??忽略了很多?東東... */
/** @group conversions-string */
@inline implicit def augmentString(x: String): StringOps = new StringOps(x)
}
private[scala] abstract class LowPriorityImplicits {
/* ??忽略了很多?東東... */
/** @group conversions-string */
implicit def wrapString(s: String): WrappedString = if (s ne null) new WrappedString(s) else null
}
String到StringOps的隱式轉(zhuǎn)換是定義在Predef對(duì)象中的即纲，而String到WrappedString的?隱式轉(zhuǎn)換是在定義在Predef的???父類LowPriorityImplicits中，所以前者比后者更特化博肋。
?還是在《Programming in Scala(Third Edition)》21.7節(jié)低斋，有一??段更詳細(xì)的說明：
one implicit conversion is more specific than another if one of the following applies:
- The argument type of the former is a subtype of the latter's.
- Both conversions are methods, and the enclosing class of the former extends the enclosing class of the latter.
Odersky?又解釋道：
The motivation to revisit this issue and revise the rule was to improve interoperation between Java collections, Scala collections, and strings.
又試著在REPL寫了一段測(cè)試代碼，的確如此：
case class A1(a: Int) {
def guess = a * 10
def what = a
}
case class A2(a: Int) {
def guess = a * 100
}
class BaseImplicits {
implicit def Int2A1(a: Int) = new A1(a)
}
object SpecificImplicits extends BaseImplicits {
implicit def Int2A2(a: Int) = new A2(a)
}
scala> import SpecificImplicits._
import SpecificImplicits._
scala> 1.guess
res1: Int = 100
scala> 1.what
res2: Int = 1
