string隐式转换的二义性问题
scala标准库在Predef对象中定义了两个String的隐式转换:
implicit def augmentString(x: String): StringOps implicit def wrapString(s: String): WrappedString
而StringOps
和WrappedString
有一些重复的方法,如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.
�两个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
更特化呢?让�我们先看看Predef对象的�继承关系:
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
的隐式转换是定义在Predef
对象中的,而String
到WrappedString
的�隐式转换是在定义在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
链接:https://www.jianshu.com/p/eb7fa9140f74
共同学习,写下你的评论
评论加载中...
作者其他优质文章