1. Unified Type System
Scala has a unified type system, enclosed by the type Any at the top of the hierarchy and the type Nothing at the bottom of the hierarchy. All Scala types inherit from Any.
# Using Any, Book extends AnyRef, and x is an Int that extends AnyVal scala> import scala.collection.mutable.ListBuffer import scala.collection.mutable.ListBuffer scala> val list = ListBuffer[Any]() list: scala.collection.mutable.ListBuffer[Any] = ListBuffer() scala> val x = 2 x: Int = 2 scala> list += x res11: list.type = ListBuffer(2) scala> class Book defined class Book scala> list += new Book res12: list.type = ListBuffer(2, Book@4894a95e) # limit a method to only be able to work on Value Types scala> def test(int: AnyVal) = () test: (int: AnyVal)Unit scala> test(5) scala> test(5.12) scala> test(new Object) <console>:10: error: type mismatch; found : java.lang.Object required: AnyVal test(new Object) ^
2. Type Parameterization
Classes and traits that take type parameters are called generic; the types they generate are called parameterized type.
# Scala List of Strings scala> val list: List[String] = List("A","B")
Note that the Set[T] is a trait, but not a type because it takes a type parameter.
# Scala requires to specify type parameters scala> def test(s: Set){} <console>:8: error: type Set takes type parameters def test(s: Set){} ^ # specifying parameter types scala> def test(s: Set[AnyRef]){} test: (s: Set[AnyRef])Unit
In Scala, List, Set and so on also be referred as a type constructors, because they are used to create specific types. You could construct a type by specifying a type parameter.
(1) Variance
A declaration like class Set[+A] means that Set is parameterized by a type A. The + is called a variance annotation【型变注释】.
Variance comes in three flavors: invariant【不变】, covariant【协变】, and contravariant【逆变】. Variance in Scala is defined by using + and - signs in front of type parameters.
1) Covariant Parameter Types
Covariant parameter types are designated with a + before the type parameter. A covariant type is useful for read-only containers.
If S extends T then Class[S] extends Class[T].
# immutable class Getable scala> class Getable[+T](val data: T) defined class Getable # define a method that takes a Getalbe scala> def get(in: Getable[Any]){println("It's "+in.data)} get: (in: Getable[Any])Unit # instance of Getable scala> val gs = new Getable("String") gs: Getable[java.lang.String] = Getable@6a6877c1 scala> get(gs) It's String #passing Double scala> def getNum(in: Getable[Number]) = in.data.intValue getNum: (in: Getable[java.lang.Number])Int scala> def gd = new Getable(new java.lang.Double(3.3)) gd: Getable[java.lang.Double] scala> getNum(gd) res17: Int = 3
We can make read-only classes covariant.
2) Contravariant Parameter Types
Contravariance indicates if S extends T, then class[T] extends Class[S].
# Putable Class scala> class Putable[-T]{def put(in: T){println("Putting "+in)}} defined class Putable # method takes a Putable[String] scala> def writeOnly(in: Putable[String]){in.put("Hello")} writeOnly: (in: Putable[String])Unit # declare an instance of Putable[AnyRef] scala> val p = new Putable[AnyRef] p: Putable[AnyRef] = Putable@3a5a8982 scala> writeOnly(p) Putting Hello
The inputs to a transformation are contravariant. Calling something that expects at least AnyRef with a String is legal and valid. But the return value can be covariant because we expect to get back a Number, so if we get an Integer, a subclass of Number, we're okay.
# define DS with a contravariant In type and a covariant Out type. scala> trait DS[-In, +Out]{def apply(i: In): Out} defined trait DS # create an instance that will convert Any into an Int scala> val t1 = new DS[Any, Int]{def apply(i: Any) = i.toString.toInt} t1: java.lang.Object with DS[Any,Int] = $anon$1@4f7620f1 scala> def check(in: DS[String, Any]) = in("333") check: (in: DS[String,Any])Any scala> check(t1) res19: Any = 333
3) Invariant Parameter Types
In Scala, Array[T] is invariant. This means that you can only pass an Array[String] to foo(a: Array[String]).
# define an invariant class scala> class Holder[T](var data: T) defined class Holder scala> def add(in: Holder[Int]){in.data = in.data + 1} add: (in: Holder[Int])Unit scala> val h = new Holder(0) h: Holder[Int] = Holder@3d85fdbe scala> add(h) scala> h.data res21: Int = 1
Because the add method expects an Int to come out of Holder and puts an Int back into the Holder, the type of the Holder must be invariant.
Let's put a Double into a Holder[Number]:
scala> val nh = new Holder[Number](33.3d) nh: Holder[java.lang.Number] = Holder@4e3540c7 scala> def round(in: Holder[Number]){in.data = in.data.intValue} round: (in: Holder[java.lang.Number])Unit scala> round(nh) scala> nh.data res4: java.lang.Number = 33
We put a Number and got back a Number.
# the underlying class scala> nh.data.getClass res5: java.lang.Class[_ <: java.lang.Number] = class java.lang.Integer # try to pass a Holder[Double] into round scala> val dh = new Holder(33.3d) dh: Holder[Double] = Holder@5a3a5cc5 scala> round(dh) <console>:11: error: type mismatch; found : Holder[Double] required: Holder[java.lang.Number] round(dh) ^
4) Rules of Variance
Mutable containers should be invariant. Immutable containers should be covariant. Inputs to transformations should be contravariant, and outputs from transformations should be covariant.
(2) Type Bounds
1) Upper Type Bounds
An Upper bound type is restricted to a specific type or one of its derived types. Scala provides the upper bound relation operator (<:). The <: operator signifies that the type to the left of the <: operator must be a subtype or be the same type of the type to the right of the <: operator.
#define an Employee class hierarchy scala> class Employee(val name: String) defined class Employee scala> class Internal(name: String) extends Employee(name) defined class Internal scala> class FreeLancer(name: String) extends Employee(name) defined class FreeLancer scala> class Customer(name: String) defined class Customer # define a function that takes a parameter with an upper bound scala> def employeeName[A <: Employee](emp: A){println(emp.name)} employeeName: [A <: Employee](emp: A)Unit scala> employeeName(new Internal("Paul")) Paul scala> employeeName(new FreeLancer("John")) John # the Customer class is not a subtype of Employee. scala> employeeName(new Customer("Peter")) <console>:11: error: inferred type arguments [Customer] do not conform to method employeeName's type parameter bounds [A <: Employee] employeeName(new Customer("Peter")) ^
2) Lower Type Bounds
A lower bound type is restricted to a specific type or its supertype. The type selected must be equal to or a supertype of the lower bound restriction.
scala> class A{ | type B >: List[Int] | def something(a: B) = a | } defined class A # instantiate the subtype scala> val st = new A{ type B = Traversable[Int]} st: A{type B = Traversable[Int]} = $anon$1@57a3687 scala> st.someMethod(Set(1,2)) res0: st.B = Set(1, 2)
Even if Set is not a supertype of the List class, it's a subtype of Traversable.
3. Implicit Class
The String class seems to have grown methods:
scala> "Hello".toList res0: List[Char] = List(H, e, l, l, o)
If you have an instance of a particular type, and you need another type, and there's an implicit conversion in scope, Scala will call the implicit method to perform the conversion.
# create a method that calculates the number of days based on a Long containing a millisecond count scala> def millisToDays(in: Long): Int = (in / (1000L*3600L*24)).toInt millisToDays: (in: Long)Int scala> millisToDays(5949440999L) res1: Int = 68 # try to pass a Date into the method scala> millisToDays(new Date) <console>:14: error: type mismatch; found : java.util.Date required: Long millisToDays(new Date) ^ # define a method that will automatically be called when we need the conversion scala> implicit def dateToLong(d: Date) = d.getTime dateToLong: (d: java.util.Date)Long scala> millisToDays(new Date) res5: Int = 17048
You should be very careful with implicit conversions, and their use should be an explicit design choice. However, we see that sometimes implicit conversions(Int -> Long) are very valuable.
# a method that takes a parameter that must be a Long scala> def m2[T <: Long](in: T):Int = (in / (1000L * 3600L * 24L)).toInt m2: [T <: Long](in: T)Int scala> m2(33) <console>:15: error: inferred type arguments [Int] do not conform to method m2's type parameter bounds [T <: Long] m2(33) ^ scala> m2(33L) res7: Int = 0
What is the scope of implicits? Scala compiler considers an implicit in the current scope if:
1) The implicit is defined in the current class or in a superclass.
2) The implicit is defined in a trait or supertrait, or is mixed into the current class or superclass
3) The implicit is defined on the companion object of the current target class.
4) The implicit is available on an object that has been imported into the current scope.
When designing libraries, be careful about defining implicits, and make sure they are in as narrow a scope as is reasonable. When consuming libraries, make sure the implicits defined in the objects are narrow enough and are not going to cause problems such a getting stuff from every Option.
An implicit class is a class marked with the implicit keyword. The keyword makes the class's primary constructor available for implicit conversions when the class is in scope.