Type与Class、ClassTag与TypeTag

Scala中获取Class的方式:
scala> class A
defined class A

scala> val a = new A
a: A = A@17a1e4ca

scala> a.getClass
res10: Class[_ <: A] = class A

scala> classOf[A]
res11: Class[A] = class A
       上面显示了两者的不同,getClass方法得到的是Class[A]的某个子类,而classOf[A]得到是正确的Class[A],但是去比较的话,这两个类型是equals为true的:
scala> a.getClass == classOf[A]
res12: Boolean = true
       这种细微的差别,体现在类型赋值时,因为java里的 Class[T]是不支持协变的,所以无法把一个Class[_ < : A] 赋值给一个 Class[A]
scala> val ab:Class[A] = a.getClass
<console>:12: error: type mismatch;
 found   : Class[?0] where type ?0 <: A
 required: Class[A]
Note: ?0 <: A, but Java-defined class Class is invariant in type T.

Scala中获取Type的方式:
scala> import scala.reflect.runtime.universe._
import scala.reflect.runtime.universe._

scala> typeOf[List[Int]]
res6: reflect.runtime.universe.Type = scala.List[Int]
       与classOf相比,typeOf返回的泛型信息更具体:
scala> classOf[List[Int]]
res8: Class[List[Int]] = class scala.collection.immutable.List

scala> classOf[List[Int]] == classOf[List[String]]
res9: Boolean = true

scala> typeOf[List[Int]] == typeOf[List[String]]
res10: Boolean = false

       Java和scala是基于JVM的,在虚拟机内部,并不关心泛型或类型系统。在JVM上,泛型参数类型T在运行时是被擦除掉的, 编译器把T当作Object来对待,所以T的具体信息是无法得到的。
       Manifest是scala2.8引入的一个特质,用于编译器在运行时也能获取泛型类型的信息。为了使得在运行时得到T的信息,scala需要额外通过Manifest来存储T的信息,并作为参数用在方法的运行时上下文。
def foo[T:Manifest] (x: List[T])
       Manifest会记录T类型信息,在运行时就可以更准确的判断T。
       在引入Manifest的时候,还引入了一个更弱一点的ClassManifest,所谓的弱是指类型信息不如Manifest那么完整。

       不过scala在2.10里用TypeTag替代了Manifest,用ClassTag替代了ClassManifest。

 Manifest与TypeTag

Manifest是scala2.8引入的一个特质,用于编译器在运行时也能获取泛型类型的信息。在JVM上,泛型参数类型T在运行时是被“擦拭”掉的,编译器把T当作Object来对待,所以T的具体信息是无法得到的;为了使得在运行时得到T的信息,scala需要额外通过Manifest来存储T的信息,并作为参数用在方法的运行时上下文。

def test[T] (x:T, m:Manifest[T]) { ... }

有了Manifest[T]这个记录T类型信息的参数m,在运行时就可以根据m来更准确的判断T了。但如果每个方法都这么写,让方法的调用者要额外传入m参数,非常不友好,且对方法的设计是一道伤疤。好在scala中有隐式转换、隐式参数的功能,在这个地方可以用隐式参数来减轻调用者的麻烦。

这里给出了一个例子摘自 StackOverflow :

 def foo[T](x: List[T])(implicit m: Manifest[T]) = {
    if (m <:< manifest[String])
      println("Hey, this list is full of strings")
    else
      println("Non-stringy list")
}

foo(List("one", "two")) // Hey, this list is full of strings
foo(List(1, 2)) // Non-stringy list
foo(List("one", 2)) // Non-stringy list

隐式参数m是由编译器根据上下文自动传入的,比如上面是编译器根据 "one","two" 推断出 T 的类型是 String,从而隐式的传入了一个Manifest[String]类型的对象参数,使得运行时可以根据这个参数做更多的事情。

不过上面的foo 方法定义使用隐式参数的方式,仍显得啰嗦,于是scala里又引入了“上下文绑定”,回顾一下之前的这篇:scala类型系统:13) context bounds,使得foo方法

def foo[T](x: List[T]) (implicit m: Manifest[T])

可以简化为:

def foo[T:Manifest] (x: List[T])

这个机制起因是scala2.8对数组的重新设计而引入的,原本只是为了解决数组的问题(后续介绍数组类型),后续被用在更多方面。在引入Manifest的时候,还引入了一个更弱一点的ClassManifest,所谓的是指类型信息不如Manifest那么完整,主要针对高阶类型的情况:

scala> class A[T]

scala> val m = manifest[A[String]]

scala> val cm = classManifest[A[String]]

根据规范里的说法,m的信息是完整的:m: Manifest[A[String]] = A[java.lang.String],而 cm 则只有 A[_] 即不包含类型参数的信息,但我在2.10下验证cm也是:cm: ClassManifest[A[String]] = A[java.lang.String]

在获取类型其类型参数时也是都包含的:

scala> m.typeArguments
res8: List[scala.reflect.Manifest[_]] = List(java.lang.String)

scala> cm.typeArguments
res9: List[scala.reflect.OptManifest[_]] = List(java.lang.String)

后来从这个帖子里,看到一些案例,只在:

scala> class A[B]  // 注意在2.10下与帖子中不一致,A[+B] 也是同样的效果
defined class A

scala> manifest[A[_]]
res15: scala.reflect.Manifest[A[_]] = A[_ <: Any]

scala> classManifest[A[_]]
res16: scala.reflect.ClassTag[A[_]] = A[<?>]

到这里我们基本明白了 Manifest 与 ClassManifest,不过scala在2.10里却用TypeTag替代了Manifest,用ClassTag替代了ClassManifest,原因是在路径依赖类型中,Manifest存在问题:

scala> class Foo{class Bar}

scala> def m(f: Foo)(b: f.Bar)(implicit ev: Manifest[f.Bar]) = ev

scala> val f1 = new Foo;val b1 = new f1.Bar
scala> val f2 = new Foo;val b2 = new f2.Bar

scala> val ev1 = m(f1)(b1)
ev1: Manifest[f1.Bar] = [email protected]#Foo$Bar

scala> val ev2 = m(f2)(b2)
ev2: Manifest[f2.Bar] = [email protected]#Foo$Bar

scala> ev1 == ev2 // they should be different, thus the result is wrong
res28: Boolean = true

ev1 不应该等于 ev2 的,因为其依赖路径(外部实例)是不一样的。

还有其他因素(见下面的引用),所以在2.10版本里,使用 TypeTag 替代了 Manifest

Manifests are a lie. It has no knowledge of variance (assumes all type parameters are co-variants), and it has no support for path-dependent, existential or structural types.

TypeTags are types as the compiler understands them. Not “like” the compiler understands them, but “as” the compiler understands them — the compiler itself use TypeTags. It’s not 1-to-1, it’s just 1. :-)



猜你喜欢

转载自blog.csdn.net/hellojoy/article/details/81064002
今日推荐