向后兼容性将被完全破坏,真的。如果您有一个简单的方法,例如:
def foo[A](a: A)(implicit something: SomeType) = ???
那么假设在Scala的下一个版本中,编译器突然ClassTag
在所有带类型参数的方法的签名中添加了隐式s。这种方法会被打破。任何被明确调用的地方foo(a)(someTypeValue)
都不再起作用。二进制和源代码兼容性将消失。
Java 互操作性将是丑陋的。假设我们的方法现在看起来像这样:
def foo[A : ClassTag](a: A) = ???
因为ClassTag
s 是由 Scala 编译器生成的,所以在 Java 中使用这种方法会更加困难。你必须ClassTag
自己创造。
ClassTag<MyClass> tag = scala.reflect.ClassTag$.MODULE$.apply(MyClass.class);
foo(a, tag);
我的 Java 可能不是 100% 正确,但你明白了。任何参数化的东西都会变得非常难看。好吧,如果它需要一个隐式的,它已经是了ClassTag
,但是需要它的方法类会急剧增加。
此外,在我们(至少是我)使用的大多数参数化方法中,类型擦除并不是什么大问题。由于上述原因,我认为为每个类型参数自动要求一个ClassTag
比它有帮助的麻烦得多。
当然,这会增加更多的编译器开销,因为它需要生成ClassTag
比通常更多的 s。我认为除非有所作为,否则它不会增加更多的运行时开销ClassTag
。例如,在像下面这样的简单方法中,ClassTag
并没有真正做任何事情:
def foo[A : ClassTag](a: A): A = a
我们还应该注意到,它们也不完美。因此,添加它们并不是消除问题的最终解决方案。
val list = List(1, "abc", List(1, 2, 3), List("a", "b"))
def find[A: ClassTag](l: List[Any]): Option[A] =
l collectFirst { case a: A => a }
scala> find[List[String]]
res2: Option[List[String]] = Some(List(1, 2, 3)) // Not quite! And no warnings, either.
ClassTag
向每个类实例添加 a会增加开销,并且肯定还会破坏兼容性。在很多地方也是不可能的。我们不能只注入java.lang.String
一个ClassTag
. 此外,我们仍然很容易被擦除。在每个类中都有一个ClassTag
字段实际上并不比使用getClass
. 我们可以进行类似的比较
case a if(a.getClass == classOf[String]) => a.asInstanceOf[String]
但这非常丑陋,需要演员阵容,而且不一定ClassTag
是要解决的问题。如果我用我的find
方法尝试这样的事情,它根本行不通。
// Can't compile
def find[A](l: List[Any]): Option[A] =
l collectFirst { case a if(a.getClass == classOf[A]) => a.asInstanceOf[A] }
即使我要以某种方式与它一起工作ClassTag
,它会从哪里来?我不能说a.classTag == classTag[A]
,因为A
已经被抹去了。我需要ClassTag
在方法调用站点。