在学习Scala的时候，隐式转换（implicit conversion）这个特性让我实在是闹不住啊。于是乎一边试用一边感慨：真的是太强大，太方便了。不过，越是强大且方便的东西，越容易用出毛病来。在我不求甚解的情况下，毛病就来了，我把它称为隐式转换优先顺序问题：

     假设我们有一个表示文本的行数的类LineNumber：

我们可以用这个类来表示一本书中每一页的行数：

上面的代码分别表示了第一页和第二页的行数。当然，我们也应该可以将它们相加，得到这两页的总行数：

这样的话，我们的LineNumber类里就应该有一个 “+” 方法来将两个对象相加：

从直观上讲，我们甚至可以直接用整数来和LineNumber相加：

写到这里我们发现，LineNumber对象中没有接受整型作为参数的 “+” 方法；而整型中也不会有接受LineNumber作为参数的 “+” 方法。

为了说明问题，我们不在LineNumber类中增加一个整型作为参数的重载方法，而是定义两个隐式转换，一个将Int转换为LineNumber，另一个将LineNumber转换为Int：

接下来再让我们尝试用LineNumber和整型相加：

我们会得到什么结果呢？

       我最初认为，Scala编译器可能会产生编译错误，毕竟我们现在的代码中对于两种类型的隐式转换都是存在的，这样的话上面两个语句的方法参数和调用方法的对象都可以做隐式转换。很明显我错了。运行结果：totalLineNumber1是一个新的LineNumber的对象，并且它的字段num会是232；而totalLineNumber2则是一个Int类型，值为232。

先让我们看看在编译时加入 “-Xprint:typer” 后上面两句的结果：

到这里已经很清楚了。Scala编译器优先选择了方法的参数作为转换对象，而没有选择调用方法的对象。这是为什么呢？

其实，当程序类型检查出现问题的时候，Scala编译器会在两个位置上对出现问题的语句尝试使用隐式转换：

• 第一个位置是 “可以直接将某个类型转换为期望的类型” 的地方
• 第二个位置是 “可以将调用方法的对象转换为合适类型” 的地方

     第一个位置是那种我们需要A但是传入的却是B的地方。上面的例子正好就是这样的情况，对于totalLineNumber1来说，lineNumOfPage1的 “+” 方法需要的参数类型是LineNumber型，然而我们传入的是Int类型，Scala编译器在这里检测到类型错误后，会寻找将Int转换为LineNumber的隐式转换。因为在代码开始时，我们利用 “import LineNumber._ ” 导入了相应的隐式转换，因此Scala编译器使用导入的隐式转换将整型120转换为了LineNumber类型。totalLineNumber2发生的情况是相同的，只不过是将LineNumber类型转换为了Int类型。

     也就是说，Scala编译器在使用隐式转换的时候，首先回去寻找可以直接转换类型的位置，其次才对调用方法的对象。如果我们将我们的隐式转换中intToLineNumber的转换去掉，那么我们得到的totalLineNumber1就会变为一个整型。

     就像我开头所说的那样，Scala的隐式转换是一个非常强大的工具，但是如果不了解它，或者将其滥用在程序中，会使得程序难以理解和维护。真的到了那个时候，就确实“闹不住”了。