标签:
王家林亲授《DT大数据梦工厂》大数据实战视频 Scala 深入浅出实战经典(1-64讲)完整视频、PPT、代码下载:
百度云盘:http://pan.baidu.com/s/1c0noOt6
腾讯微云:http://url.cn/TnGbdC
360云盘:http://yunpan.cn/cQ4c2UALDjSKy 访问密码 45e2
技术爱好者尤其是大数据爱好者 可以加DT大数据梦工厂的qq群
DT大数据梦工厂① :462923555
DT大数据梦工厂②:437123764
DT大数据梦工厂③ :418110145
微信公众账号: DT_Spark
王家林老师微信号: 18610086859
王家林老师QQ: 1740415547
王家林老师邮箱: 18610086859@126.com
本视频由王家林老师, 亲自讲解, 完全通过代码实战把您带人大数据的时代.
package com.parllay.scala.type_parameterizitor /** * Created by richard on 15-7-30. * 第46讲: ClassTag 、Manifest、ClasMainifest TagType实战 */ object Manifest_Class { def main(args: Array[String]) { /** 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里又引入了“上下文绑定”, 回顾一下之前 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] = Foo@681e731c.type#Foo$Bar scala> val ev2 = m(f2)(b2) ev2: Manifest[f2.Bar] = Foo@3e50039c.type#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. :-) */ } }
Scala 深入浅出实战经典 第46讲: ClassTag 、Manifest、ClasMainifest TagType实战
标签:
原文地址:http://www.cnblogs.com/czh-liyu/p/4694395.html