Scala 什么时候发生类型擦除？

scala的语法非常有前途。我原以为scala不仅仅是舒适的java，还可以引入全新的编程范式，但语法允许的许多特性在语义上是不正确的。所以我开始寻找scala的局限性，并通过黑客来消除它们。虽然我只是写了一个测试项目来适应scala的方式和模式

主要障碍是从jvm实现继承的类型擦除。我可以写一篇小文章，名为“打字擦除毁掉的十种美丽图案”。据说类型擦除会污染泛型，但我在mixin中偶然发现了类型擦除。我认为Scala中的MIXIN实现存在问题。

序言

trait T1
trait T2

trait B1 {
  def typeMe(x:T1){}
}

带mixin的坏代码

trait B2 extends B1 {
  def typeMe(x:T1 with T2) {}
}

将mixin声明为单独特征的工作代码

trait T3 extends T1 with T2
trait B3 extends B1 {
  def typeMe(x:T3) {}
}

错误是：

error: name clash between defined and inherited member:
method typeMe:(x: T1 with T2)Unit and
method typeMe:(x: T1)Unit in trait B1
have same type after erasure: (x: $line12.$read#$iw#$iw#T1)Unit
    def typeMe(x:T1 with T2)

可用的最佳解决方案是什么？引入新特性是冗长的（特别是对于大型mixin链），并导致类型不兼容。添加模拟隐式参数也不是万能的，因为它会增加开销

---

更新：

---

非常抱歉，我问错了问题。我更感兴趣的是所描述的错误的性质，而不是它的解决方法。类型擦除发生在哪里？我在被认为是类型擦除源的代码中没有看到泛型。编译器行为背后的机制是什么？

您尝试执行的操作有几个问题

首先，类型擦除何时发生并不重要。这是因为类型擦除的概念是，无论在计算之前还是之后擦除类型，结果都应该是相同的。对于JVM语言，一些擦除在编译时发生，iinm

---

其次，你的“工作”代码实际上并不像你想象的那样工作。这需要对子类型、协方差和逆变换有一点了解。（<代码> fob v）只有当代码> w时，您可以考虑重载方法的替代；命名它们不同或使用Type CelpScript模式。我希望您意识到，在<代码> B3中，您并不是重写方法<代码> Type EM> <代码> >代码> B1 < /C> >，但重载它采取子类型。调用的方法将取决于局部变量的类型。即，假设一个

B3

对象

B3

和一个

T3

对象

T3

，

B3.typeMe（T3）

和

B3.typeMe（T3:T1）

将调用不同的方法。我写的不是实际问题。主要问题是类型擦除发生在哪里，错误背后的泛型是什么。

B1.typeMe(x:T1)
B3.typeMe(x:T3)