從"hello".count想到的之二--scal

tankII發表於2021-09-09

string隱式轉換的二義性問題

scala標準庫在中定義了兩個String的隱式轉換:

implicit def augmentString(x: String): StringOps
implicit def wrapString(s: String): WrappedString

StringOpsWrappedString有一些重複的方法,如count
中定義了count方法

def count(p: (Char)  Boolean): Int
Counts the number of elements in the traversable or iterator which satisfy a predicate.

也有count方法

def count(p: (Char)  Boolean): Int
Counts the number of elements in the traversable or iterator which satisfy a predicate.

�兩個count方法��完全一樣,應該存在二義性問題啊。試著在REPL中寫了�一�段隱式轉換的程式碼,果然會提示有二義性:

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

但是從可以知道"hello".count不但沒有報錯,還會選擇StringOps.count。�為什麼會這樣呢?

�隱式轉換的最佳化級

Martin Odersky親自寫的《Programming in Scala(Third Edition)》21.7節最後有下面這一段說明:

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.

簡而言之,編譯器之所以會選擇StringOps而不是WrappedString,是因為StringOps特化(more specific)。為什麼說StringOps更特化呢?讓�我們先看看的�繼承關係:

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}

StringStringOps的隱式轉換是定義在Predef物件中的,而StringWrappedString的�隱式轉換是在定義在Predef的���父類LowPriorityImplicits中,所以前者比後者更特化。
�還是在《Programming in Scala(Third Edition)》21.7節,有一��段更詳細的說明:

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寫了一段測試程式碼,的確如此:

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.guessres1: Int = 100scala> 1.whatres2: Int = 1



作者:typesafe
連結:


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/1795/viewspace-2818785/,如需轉載,請註明出處,否則將追究法律責任。

相關文章