Desugar Scala(16) -- Lower Bound

欢迎关注我的新博客地址:http://cuipengfei.me/

 

Lower bound,不知道这个词的确切中文翻译是怎样的。我们直接看例子吧。

1

2 3 
class Pair[T](val first: T, val second: T) {  def replaceFirst[R >: T](newFirst: R): Pair[R] = new Pair[R](newFirst, second) } 

我们定义一个叫做Pair的类,其中可以包含两个元素,元素类型为泛型的T。

Pair类中有一个replaceFirst方法,用来把第二个元素和一个新的元素结合起来组成一个新的Pair。新的元素的类型是泛型的R。新组成的Pair的类型是Pair[R]。

到这里我们就要想了,一个T和一个R,它们俩怎么组成新的Pair呢?新的Pair的类型怎么能是Pair[R]呢?

replaceFirst的签名给我们说明了这一点。[R >: T]。这种标记的含义是说R是T的基类。那么一个T和一个R自然可以组合成一个R的Pair了。

单是这样干说,有点不好理解,我们看一个例子:

1

2 3 4 5 
class Vehicle {}  class Car extends Vehicle {}  class Tank extends Vehicle {} 

汽车和坦克都是机动车。

然后我们可以这样使用它们:

1

2 
 val twoCars: Pair[Car] = new Pair(new Car(), new Car())  val tankAndCar: Pair[Vehicle] = twoCars.replaceFirst(new Tank()) 

首先我们用两辆汽车组成一个Pair,其类型为Pair[Car]。

然后我们用一辆坦克替代原来的Pair中的第一个元素,让坦克和第二辆车组成一个新的Pair。新的Pari的类型是Pair[Vehicle]。

这里有一点tricky。我们调用replaceFirst的时候传递的参数的类型是Tank,这是否意味着在这里R就是Tank呢?

不是的,因为很明显Tank不是Car的基类,然而Tank是一个(is a)Vehicle,Vehicle同时也是Car的基类。于是此处的R就是Vehicle。得到的新的Pair自然就是Pair[Vehicle]。

也就是说R会被什么具体类型替换呢?这取决于T和newFirst的类型。

如果newFirst的类型刚好是T的基类,那太好了,R就直接是newFirst的类型。如果newFirst的类型不是T的基类,那R就会是T和newFirst的类型的共同基类。

这个东西挺麻烦的,它有啥用呢?

保证类型安全,Java没有提供给我们的类型安全。

还是刚才的那段代码:

1

2 
 val twoCars: Pair[Car] = new Pair(new Car(), new Car())  val tankAndCar: Pair[Vehicle] = twoCars.replaceFirst(new Tank()) 

其中的第二行,Scala可以很聪明的推断出replaceFirst的返回值类型是Pair[Vehicle]。实际上,如果我们试图把tankAndCar声明为Pair[Tank]的话,会看到编译时错误。

而类似的代码在Java里则没有这么幸运了:

1

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 
public class PairJ<T> {  private T first;  private T second;   public PairJ(T first, T second) {  this.first = first;  this.second = second;  }   public T first() {  return this.first;  }   public T second() {  return this.second;  }   public <R> Pair<R> replaceFirst(R newFirst) {  return new Pair(newFirst, second());  } } 

为了标明区别,我们这次称之为PairJ。到这里忍不住要小小的黑Java一下,21行代码,和Scala的3行是等价的:)

我们重点看一下replaceFirst在这里的声明,其中声明了一个泛型参数R,但是R和T是没有任何关系的。实际上,在Java中,我们无法表达方法的泛型参数和类型的泛型参数之间的关系。(其原因请参看这里

我们写出如下的代码:

1

2 
 PairJ<Car> twoCars = new PairJ(new Car(), new Car());  Tank actuallyACar = twoCars.replaceFirst(new Tank()).second(); 

先创建两辆车的Pair,然后把第一辆车替换成坦克。再把新组成的Pair里面的第二个元素(其类型是车)取出来,赋值给一个类型为坦克的变量。

如果我们编译这段代码,Java编译器会允许其通过。但是运行起来就会跑出类型转换异常。原因很明显,Car不能转换成Tank。

这个,就是刚才所说的类型安全性上的差异。

等等,脱衣服的部分呢?

之前的每一篇博客都会把Scala代码编译出的bytecode反编译成Java,来探索其语言特性是如何实现的。

而这一次颇为不同。之前的语言特性虽说Scala写起来比Java会简便一些,但是还没有超出Java的能力范围。多费点劲,用Java还是能做到。

而这一次,这种编译时类型安全检验的严格性,实在是在Java中无法表达的。这全靠了Scala编译器的功劳。

这就意味着,上面所定义的Pair这个类,如果你在Java中使用它,就会失去这种类型安全性。

Scala,这次算你牛,没扒掉你。

你可能感兴趣的:(scala)