There is an experimental feature in Scala (since version 2.7.2), called Manifests, that captures type information that is erased in the byte code. This feature is not documented in the Scaladocs, but you can examine the source for the scala.reflect.Manifest trait. [Ortiz2008] discusses Manifests and provides examples of their use.

A Manifest is declared as an implicit argument to a method or type that wants to capture the erased type information. Unlike most implicit arguments, the user does not need to supply an in-scope Manifest value or method. Instead, the compiler generates one automatically. Here is an example the illustrates some of the strengths and weaknesses of Manifests.

// code-examples/TypeSystem/manifests/manifest-script.scala

import scala.reflect.Manifest

object WhichList {
  def apply[B](value: List[B])(implicit m: Manifest[B]) = m.toString match {
    case "int"              => println( "List[Int]" )
    case "double"           => println( "List[Double]" )
    case "java.lang.String" => println( "List[String]" )
    case _                  => println( "List[???]" )
  }
}

WhichList(List(1, 2, 3))
WhichList(List(1.1, 2.2, 3.3))
WhichList(List("one", "two", "three"))

List(List(1, 2, 3), List(1.1, 2.2, 3.3), List("one", "two", "three")) foreach {
  WhichList(_)
}

WhichList tries to determine the type of list passed in. It uses the value of the manifest’s toString method to determine this information. Notice that it works when the list is constructed inside the call to WhichList.apply. It does not work when a previously constructed list is passed to WhichList.apply.

The compiler exploits the type information it knows in the first case to construct the implicit Manifest with the correct B. However, when given previously-constructed lists, the crucial type information is already lost.

Hence, Manifests can’t “resurrect” type information from byte code, but they can be used capture and exploit type information before it is erased.

Individual methods can also be parameterized. Good examples are the apply methods in companion objects for parameterized classes. Recall that companion objects are singleton objects associated with a companion class. There is only one instance of a singleton object, as its name implies, so type parameters would be meaningless.

Let’s consider object List, the companion object for class List[+A]. Here is the definition of the apply method in object List.

def apply[A](xs: A*): List[A] = xs.toList

The apply methods takes a variable length list of arguments of type A, which will be inferred from the arguments, and returns a list created from the arguments. Here is an example.

val languages = List("Scala", "Java", "Ruby", "C#", "C++", "Python", ...)
val positiveInts = List(1, 2, 3, 4, 5, 6, 7, ...)

We’ll look at other parameterized methods below.

All the parameterized types we’ve discussed so far have been immutable types. What about the variance behavior of mutable types? The short answer is that only invariance is allowed. Consider this example.

// code-examples/TypeSystem/variances/mutable-type-variance-script.scala
// WON'T COMPILE: Mutable parameterized types can't have variance annotations

class ContainerPlus[+A](var value: A)      // ERROR
class ContainerMinus[-A](var value: A)     // ERROR

println( new ContainerPlus("Hello World!") )
println( new ContainerMinus("Hello World!") )

Running this script throws the following errors.

... 4: error: covariant type A occurs in contravariant position in type A     of parameter of setter value_=
class ContainerPlus[+A](var value: A)      // ERROR
                             ^
... 5: error: contravariant type A occurs in covariant position in type => A     of method value
class ContainerMinus[-A](var value: A)     // ERROR
                              ^
two errors found

We can make sense of these errors by remembering our discussion of FunctionN type variance under inheritance, where the types of the function arguments are contravariant (i.e., -T1) and the return type is covariant (i.e., +R).

The problem with a mutable type is that at least one of its fields has the equivalent of read and write operations, either through direct access or through accessor methods.

In the first error, we are trying to use a covariant type as an argument to a setter (write) method, but we saw from our discussion of function types that argument types to a method must be contravariant. A covariant type is fine for the getter (read) method.

Similarly, for the second error, we are trying to use a contravariant type as the return value of a read method, which must be covariant. For the write method, the contravariant type is fine.

Hence, the compiler won’t let us use a variance annotation on a type that is used for a mutable field. For this reason, all the mutable parameterized types in the Scala library are invariant in their type parameters. Some of them have corresponding immutable types that have covariant or contravariant parameters.

As we said, the variance behavior is defined at the declaration site in Scala. In Java, it is defined at the call site. The client of a type defines the variance behavior desired [Naftalin2006]. In other words, when you use a Java generic and specify the type parameter, you also specify the variance behavior (including invariance, which is the default). You can’t specify variance behavior at the definition site in Java, although you can use expressions that look similar. Those expressions define type bounds, which we’ll discuss below.

In Java variance specifications, a wild card ‘?’ always appears before the super or extends keyword, as shown in the previous table. When we said after the table that the “Java Equivalent” column is a bit misleading, we were referring to the differences between declaration vs. call site specifications. There is another way in which the Scala and Java behaviors differ, which we’ll cover in the section called “Existential Types” below.

A drawback of call-site variance specifications is that they force the users of Java generics to understand the type system more thoroughly than is necessary for Scala users, who don’t need to specify this behavior when using parameterized types. (Scala users also benefit greatly from type inference.)

Let’s look at a Java example, a simplified Java version of Scala’s Option, Some, and None types.

// code-examples/TypeSystem/variances/Option.java

package variances;

abstract public class Option<T> {
  abstract public boolean isEmpty();

  abstract public T get();

  public T getOrElse(T t) {
    return isEmpty() ? t : get();
  }
}

// code-examples/TypeSystem/variances/Some.java

package variances;

public class Some<T> extends Option<T> {

  public Some(T value) {
    this.value = value;
  }

  public boolean isEmpty() { return false; }

  private T value;

  public T get() { return value; }

  public String toString() {
    return "Option(" + value + ")";
  }
}

// code-examples/TypeSystem/variances/None.java

package variances;

public class None<T> extends Option<T> {

  public boolean isEmpty() { return true; }

  public T get() { throw new java.util.NoSuchElementException(); }

  public String toString() {
    return "None";
  }
}

Here is an example that uses this Java Option hierarchy.

// code-examples/TypeSystem/variances/OptionExample.java

package variances;
import java.io.*;
import shapes.*;  // From "Introducing Scala" chapter

public class OptionExample {
  static String[] shapeNames = {"Rectangle", "Circle", "Triangle", "Unknown"};
  static public void main(String[] args) {

    Option<? extends Shape> shapeOption =
      makeShape(shapeNames[0], new Point(0.,0.), 2., 5.);
    print(shapeNames[0], shapeOption);

    shapeOption = makeShape(shapeNames[1], new Point(0.,0.), 2.);
    print(shapeNames[1], shapeOption);

    shapeOption = makeShape(shapeNames[2],
      new Point(0.,0.), new Point(2.,0.), new Point(0.,2.));
    print(shapeNames[2], shapeOption);

    shapeOption = makeShape(shapeNames[3]);
    print(shapeNames[3], shapeOption);
  }

  static public Option<? extends Shape> makeShape(String shapeName,
      Object... args) {
    if (shapeName == shapeNames[0])
      return new Some<Rectangle>(new Rectangle((Point) args[0],
        (Double) args[1], (Double) args[2]));
    else if (shapeName == shapeNames[1])
      return new Some<Circle>(new Circle((Point) args[0], (Double) args[1]));
    else if (shapeName == shapeNames[2])
      return new Some<Triangle>(new Triangle((Point) args[0],
        (Point) args[1], (Point) args[2]));
    else
      return new None<Shape>();
  }

  static void print(String name, Option<? extends Shape> shapeOption) {
    System.out.println(name + "? " + shapeOption);
  }
}

OptionExample.main uses the Shape hierarchy from Chapter 1, Zero to Sixty: Introducing Scala, but we have updated it slightly to exploit features that we’ve learned since then, such as case classes.

// code-examples/TypeSystem/shapes/shapes.scala

package shapes {
  case class Point(x: Double, y: Double) {
    override def toString() = "Point(" + x + "," + y + ")"
  }

  abstract class Shape() {
    def draw(): Unit
  }

  case class Circle(center: Point, radius: Double) extends Shape {
    def draw() = println("Circle.draw: " + this)
  }

  case class Rectangle(lowerLeft: Point, height: Double, width: Double)
        extends Shape {
    def draw() = println("Rectangle.draw: " + this)
  }

  case class Triangle(point1: Point, point2: Point, point3: Point)
        extends Shape() {
    def draw() = println("Triangle.draw: " + this)
  }
}

Running OptionExample with scala -cp ... variances.OptionExample produces the following output.

Rectangle? Option(Rectangle(Point(0.0,0.0),2.0,5.0))
Circle? Option(Circle(Point(0.0,0.0),2.0))
Triangle? Option(Triangle(Point(0.0,0.0),Point(2.0,0.0),Point(0.0,2.0)))
Unknown? None

By the way, we are also demonstrating Scala-Java interoperability, which we’ll revisit in the section called “Java Interoperability” in Chapter 14, Scala Tools, Libraries and IDE Support.

OptionExample.main calls the static factory method makeShape, whose arguments are the name of a geometric shape and a variable length list of parameters to pass to the Shape constructors.

Note that makeShape returns Option<? extends Shape> and when we instantiate a Shape, we return a Some parameterized with the Shape subtype it wraps. If an unknown shape name is passed in, then we return a None<Shape>. We must parameterize a None instance with Shape. Because Scala defines a subtype of all types, Nothing, Scala can define None as case object None extends Option[Nothing].

The Java type system provides no way to implement our Java None in a similar way. Having a singleton object None has a number of advantages, including greater efficiency, because we aren’t creating lots of little objects, and unambiguous behavior of equals, because we don’t need to define the semantics of equality between different type instantiations of our Java None<?> type, for example, None<String> vs. None<Shape>.

Finally, note that OptionExample, a client of Option, has to specify type variance, Option<? extends Shape> in several places. In Scala, the client doesn’t carry this burden.

The implementation of parameterized types and methods is worth noting. The implementations are generated when the defining source file is compiled. For each type parameter, the implementation assumes that Any subtype could be specified (Object is used in Java generics). These aspects have performance implications that we will revisit when we discuss the @specialized annotation in the section called “Annotations” in Chapter 13, Application Design.

Consider the overloaded apply methods in object scala.Array that create new arrays. There are optimized implementations for each of the AnyVal types. There is another implementation of apply that is parameterized for any type that is a subtype of AnyRef. Here is the implementation in Scala version 2.7.5.

object Array {
  ...
  def apply[A <: AnyRef](xs: A*): Array[A] = {
    val array = new Array[A](xs.length)
    var i = 0
    for (x <- xs.elements) { array(i) = x; i += 1 }
    array
  }
  ...
}

The type parameter A <: AnyRef means “any type A that is a subtype of AnyRef”. Note that a type is always a subtype and a supertype of itself, so A could also equal AnyRef. So the <: operator indicates that the type to the left must be derived from the type to the right, or that they must be the same type. As we said in the section called “Reserved Words” in Chapter 2, Type Less, Do More, this operator is actually a reserved word in the language.

These bounds are called upper type bounds, following the de facto convention that diagrams of type hierarchies put subtypes below their supertypes. We followed this convention in the diagram shown in the section called “The Scala Type Hierarchy” in Chapter 7, The Scala Object System.

Without the bound in this case, i.e., if the signature were def apply[A](xs: A*): Array[A], the declaration would be ambiguous with the other apply methods for each of the AnyVal types.

Keep in mind the distinction between type variance and type bounds. For a type like List, the variance behavior describes how actual types instantiated from it, like List[AnyRef] and List[String], are related. In this case, List[String] is a subtype of List[AnyRef], since String is a subtype of AnyRef.

In contrast, lower and upper type bounds limit the allowed types that can be used for a type parameter when instantiating a type from a parameterized type. For example, def apply[A <: AnyRef]… says that any type used for A must be a subtype of AnyRef.

Similarly, there are circumstances when we might want to express that only supertypes of a particular type are allowed. (Recall that a type is also a supertype of itself.) We call these lower type bounds, again because the allowed type would be above the boundary in a typical type hierarchy diagram.

A particularly interesting example is the :: (“cons”) method in class List[+A]. Recall that this operator is used to create a new list by prepending an element to a list.

class List[+A] {
  ...
  def ::[B >: A](x : B) : List[B] = new scala.::(x, this)
  ...
}

The new list will be of type List[B], specifically a scala.::. The :: class (as opposed to the :: method) is derived from List. We’ll come back to it in a moment.

The :: method can prepend an object of a different type from A, the type of the elements in the original list. The compiler will infer the closest common supertype for A and the parameter x. It will use that supertype as B. Here’s an example that prepends a different type of object on a list.

// code-examples/TypeSystem/bounds/list-ab-script.scala

val languages = List("Scala", "Java", "Ruby", "C#", "C++", "Python")
val list = 3.14 :: languages
println(list)

The script prints the following output.

List(3.14, Scala, Java, Ruby, C#, C++, Python)

The new list of type List[Any], since Any is the closest common supertype of String and Double. We started with a list of Strings, so A was String. Then we prepended a Double, so the compiler inferred B to be Any, the closest (and only) common supertype.

Putting these features together, it’s worth looking at the implementation of the List class in the Scala library. It illustrates several useful idioms for functional-style, immutable data structures that are fully type safe, yet flexible. We won’t show the entire implementation, and we’ll omit the object List, many methods in the List class, and the comments that are used to generate the Scaladocs. We encourage you to look at the complete implementation of List, either by downloading the source distribution from the Scala web site [Scala] or by browsing to the implementation through the Scaladocs page for List. To avoid confusion with scala.List, we’ll use our own package and name, AbbrevList.

// code-examples/TypeSystem/bounds/abbrev-list.scala
// Adapted from scala/List.scala in the Scala version 2.7.5 distribution.

package bounds.abbrevlist

sealed abstract class AbbrevList[+A] {

  def isEmpty: Boolean
  def head: A
  def tail: AbbrevList[A]

  def ::[B >: A] (x: B): AbbrevList[B] = new bounds.abbrevlist.::(x, this)

  final def foreach(f: A => Unit) = {
    var these = this
    while (!these.isEmpty) {
      f(these.head)
      these = these.tail
    }
  }
}

// The empty AbbrevList.

case object AbbrevNil extends AbbrevList[Nothing] {
  override def isEmpty = true

  def head: Nothing =
    throw new NoSuchElementException("head of empty AbbrevList")

  def tail: AbbrevList[Nothing] =
    throw new NoSuchElementException("tail of empty AbbrevList")
}

// A non-empty AbbrevList characterized by a head and a tail.

final case class ::[B](private var hd: B,
    private[abbrevlist] var tl: AbbrevList[B]) extends AbbrevList[B] {

  override def isEmpty: Boolean = false
  def head : B = hd
  def tail : AbbrevList[B] = tl
}

Notice that while AbbrevList is immutable, the internal implementation uses mutable variables, e.g., in forEach.

There are three types defined, forming a sealed hierarchy. AbbrevList (the analog of List) is an abstract trait that declares three abstract methods, isEmpty, head, and tail. It defines the “cons” operator, :: and a foreach method. All the other methods found in List could be implemented with these methods, although some methods (like List.length) use different implementation options for efficiency.

AbbrevNil is the analog of Nil. It is a case object that extends AbbrevList[Nothing]. It returns true from isEmpty and it throws an exception from head and tail. Because AbbrevNil (and Nil) have essentially no state and behavior, having an object rather than a class eliminates unnecessary copies, makes equals fast and simple, etc.

The :: class is the analog of scala.:: derived from List. It is declared final. Its arguments are the element to become the head of the new list and an existing list, which will be the tail of the new list. Note that these values are stored directly as fields. The head and tail methods defined in AbbrevList are just reader methods for these fields. There is no other data structure required to represent the list.

This is why prepending a new element to create a new list is an O(1) operation. The List class also has a deprecated method + for creating a new list by appending an element to the end of an existing list. That operation is O(N), where N is the length of the list.

As you build up new lists by prepending elements to other lists, a nested hierarchy of :: instances is created. Because the lists are immutable, there are no concerns about corruption if one of the :: is changed in some way.

You can see this nesting if you print out a list, exploiting the toString method generated because of the case keyword. Here is an example scala session.

$ scala -cp ...
Welcome to Scala version 2.7.5.final ...
Type in expressions to have them evaluated.
Type :help for more information.

scala> import bounds.abbrevlist._
import bounds.abbrevlist._

scala> 1 :: 2 :: 3 :: AbbrevNil
res1: bounds.abbrevlist.AbbrevList[Int] = ::(1,::(2,::(3,AbbrevNil)))

Note the output on the last line, which shows the nesting of (head,tail) elements.

For another example using similar approaches, this time for defining a Stack, see http://www.scala-lang.org/node/129.

We’ve seen many examples where an implicit method was used to convert one type to another, for example to give the appearance of adding new methods to an existing type, the so-called “pimp my library” pattern. We used this pattern extensively in Chapter 11, Domain-Specific Languages in Scala. You can also use function values that have the implicit keyword. We’ll see an examples of both shortly.

A view is an implicit value of function type that converts a type A to B. The function has the type A => B or (=> A) => B (recall that (=> A) is a by-name parameter). An in-scope implicit method with the same signature can also be used as a view, e.g., an implicit method imported from an object. The term view conveys the sense of having a view from one type (A) to another type (B).

A view is applied in two circumstances.

A common example of the second circumstance is the x -> y initialization syntax for Maps, which triggers invocation of Predef.anyToArrowAssoc(x), as we discussed in the section called “The Predef Object” in Chapter 7, The Scala Object System.

For an example of the first circumstance, Predef also defines many views for converting between AnyVal types and for converting an AnyVal type to its corresponding java.lang type. For example, double2Double converts a scala.Double to a java.lang.Double.

A view bound in a type declaration is indicated with the <% keyword, e.g., A <% B. It allows any type to be used for A if it can be converted to B using a view.

A method or class containing such a type parameter is treated as being equivalent to a corresponding method or class with an extra argument list with one element, a view. For example, consider the following method defintion with a view bound.

def m [A <% B](arglist): R = ...

It is effectively the same as this method definition.

def m [A](arglist)(implicit viewAB: A => B): R = ...

(The implicit parameter viewAB would be given a unique name by the compiler.) Note that we have an additional argument list, as opposed to an additional argument in the existing argument list.

Why does this transformation work? We said that a valid A must have a view in scope that transforms it to a B. The implicit viewAB argument will get invoked inside m to convert all A instances to B instances where needed.

For this to work, there must be a view of the correct type in scope to satisfy the implicit argument. You could also pass a function with the correct signature explicitly as the second argument list when you call m. However, there is one situation where this won’t work, which we’ll describe after our example below.

For view bounds on types, the implicit view argument list would be added to the primary constructor.

To make this more concrete, let’s use view bounds to implement a LinkedList class that uses Nodes, where each Node has a payload and a reference to the next Node in the list. First, here is a hierarchy of Nodes.

// code-examples/TypeSystem/bounds/node.scala

package bounds

abstract trait Node[+A] {
  def payload: A
  def next: Node[A]
}

case class ::[+A](val payload: A, val next: Node[A]) extends Node[A] {
  override def toString =
    String.format("(%s :: %s)", payload.toString, next.toString)
}

object NilNode extends Node[Nothing] {
  def payload = throw new NoSuchElementException("No payload in NilNode")
  def next    = throw new NoSuchElementException("No next in NilNode")

  override def toString = "*"
}

This type hierarchy is modeled after List and AbbrevList above. The :: type represents intermediate nodes and NilNode is analogous to Nil for Lists. We also override toString to give us convenient output, which we’ll examine shortly.

The following script defines a LinkedList type that uses Nodes.

// code-examples/TypeSystem/bounds/view-bounds-script.scala

import bounds._

implicit def any2Node[A](x: A): Node[A] = bounds.::[A](x, NilNode)

case class LinkedList[A <% Node[A]](val head: Node[A]) {

  def ::[B >: A <% Node[B]](x: Node[B]) =
    LinkedList(bounds.::(x.payload, head))

  override def toString = head.toString
}

val list1 = LinkedList(1)
val list2 = 2 :: list1
val list3 = 3 :: list2
val list4 = "FOUR!" :: list3

println(list1)
println(list2)
println(list3)
println(list4)

It starts with a definition of a parameterized implicit method, any2Node, that converts A to Node[A]. It will be used as the implicit view argument when we work with LinkedLists. It creates a “leaf” node using a bounds.:: node with a reference to NilNode as the “next” element in the list.

An alternative would be a function value that converts Any to Node[Any].

implicit val any2Node = (a: Any) => bounds.::[Any](a, NilNode)

Otherwise, the script would run the same, except that some of the temporary lists would be using Node[Any] rather than Node[Int].

Look at the declaration of LinkedList.

case class LinkedList[A <% Node[A]](val head: Node[A]) { ... }

It defines a view bound on A and takes a single argument, the head Node of the list (which may be the head of a chain of Nodes). As we see later in the script, even though the constructor expects a Node[A] argument, we can pass it an A and the implicit view any2Node will get invoked. The beauty of this approach is that a client never has to worry about proper construction of Nodes. The machinery handles that process automatically.

The class also has a “cons” operator.

def ::[B >: A <% Node[B]](x: Node[B]) = ...

The type parameter means ``B is lower bounded by (i.e., is a supertype of) A and B also has a view bound of B <% Node[B]. As we saw for List and AbbrevList, the lower bound allows us to prepend items of different types from the original A type. This method will have its own implicit view argument, but our parameterized, implicit method, any2Node, will be used for this argument, too.

We mentioned previously that if you don’t have a view in scope, you could pass a “non-implicit” converter as the second argument list explicitly. This actually won’t work in our example, because the constructor and :: method in LinkedList take Node[A] arguments, but we call them with Ints and Strings. We would have to call them with Node[Int] and Node[String] arguments explicitly. We would also have to invoke :: in an ugly way, val list2 = list1.::(2)(converter), for example.

Let’s clarify the syntax a bit. When you see B >: A <% Node[B], it’s tempting to assume that the <% should apply to A in this expression. It actually applies to B. The grammar for type parameters, including view bounds, is the following [ScalaSpec2009].

TypeParam ::= (id | ‘_’) [TypeParamClause] [‘>:’ Type] [‘<:’ Type] [‘<%’ Type]
TypeParamClause ::= ‘[’ VariantTypeParam {‘,’ VariantTypeParam} ‘]’
VariantTypeParam ::= [‘+’ | ‘’] TypeParam

So, yes, you can have some very complex, hierarchical types! In our :: method, the id is B, the TypeParamClause is empty, and we have the >: A and <% Node[B] expressions on the right. Again, all the bounds expressions apply to the first id (B) or the underscore ‘_’.

The underscore ‘_’ is used for existential types, which we’ll cover below, in the section called “Existential Types”.

Finally, we create a LinkedList in the script, prepend some values to create new lists, and then print them out.

1 :: *
2 :: 1 :: *
3 :: 2 :: 1 :: *
FOUR! :: 3 :: 2 :: 1 :: *

To recap, the view bounds let us work with “payloads” of Ints and Strings while the implementation handled the necessary conversions to Nodes.

View bounds are not used as often as upper and lower bounds, but they provide an elegant mechanism for those times when automatic coercion from one type into another is useful. As always, use implicits with caution; implicit conversions are far from obvious when reading code and debugging mysterious behavior.

When should you use parameterized types vs. abstract types? Parameterized types are the most natural fit for parameterized container types like List and Option. Consider the declaration of Some from the standard library.

case final class Some[+A](val x : A) { ... }

If we tried to convert this to use abstract types, we might start with the following.

case final class Some(val x : ???) {
  type A
  ...
}

What should be the type of the field x? We can’t use A because it’s not in scope at the point of the constructor argument. We could use Any, but that defeats the value of having appropriately-typed declarations.

If a type will have constructor arguments declared using a “placeholder” type that has not yet been defined, then parameterized types are the only good solution (short of using Any or AnyRef).

You can use abstract types as method arguments and return values within a function. However, two problems can arise. First, you can run into problems with path-dependent types (discussed below in the section called “Path-Dependent Types”), where the compiler thinks you are trying to use an incompatible type in a particular context when in fact they are paths to compatible types. Second, it’s awkward to express methods like List.:: (“cons”) using abstract types where type changes (expansion in this case) can occur.

class List[+A] {
  ...
  def ::[B >: A](x : B) : List[B] = new scala.::(x, this)
  ...
}

Also, if you want to express variance under inheritance that is tied to the type abstractions, then parameterized types with variance annotations make these behaviors obvious and explicit.

These limitations of abstract types really reflect the tension between object-oriented inheritance and the origin of abstract types in pure functional programming type systems, which don’t have inheritance. Parameterized types are more popular in object-oriented languages because they handle inheritance more naturally in most circumstances.

On the other hand, sometimes it’s useful to refer to a type abstraction as a member of another type, as opposed to a parameter used to construct new types from a parameterized type. Refining an abstract type declaration through a series of enclosing type refinements can be quite elegant.

trait T1 {
  type t
  val v: t
}
trait T2 extends T1 {
  type t <: SomeType1
}
trait T3 extends T2 {
  type t <: SomeType2  // where SomeType2 <: SomeType1
}
class C extends T3 {
  type t = Concrete    // where Concrete <: SomeType2
  val v = new Concrete(...)
}
...

This example also shows that abstract types are often used to declare abstract variables of the same type. Less frequently, they are used for method declarations.

When the abstract variables are eventually made concrete, they can either be defined inside the type body, much as they were originally declared, or they can be initialized through constructor arguments. Using constructor arguments lets the user decide on the actual values, while initializing them in the body lets the type designer decide on the appropriate value.

We used constructor arguments in the brief BulkReader example we presented in the section called “Abstract Types And Parameterized Types” in Chapter 2, Type Less, Do More.

// code-examples/TypeLessDoMore/abstract-types-script.scala

import java.io._

abstract class BulkReader {
  type In
  val source: In
  def read: String
}

class StringBulkReader(val source: String) extends BulkReader {
  type In = String
  def read = source
}

class FileBulkReader(val source: File) extends BulkReader {
  type In = File
  def read = {
    val in = new BufferedInputStream(new FileInputStream(source))
    val numBytes = in.available()
    val bytes = new Array[Byte](numBytes)
    in.read(bytes, 0, numBytes)
    new String(bytes)
  }
}

println( new StringBulkReader("Hello Scala!").read )
println( new FileBulkReader(new File("abstract-types-script.scala")).read )

If you come from an object-oriented background, you will naturally tend to use parameterized types more often than abstract types. The Scala standard library tends to emphasize parameterized types, too. Still, you should learn the merits of abstract types and use them when they make sense.

For a class C, you can use C.this or this inside the body to refer to the current instance.

class C1 {
  var x = "1"
  def setX1(x:String) = this.x = x
  def setX2(x:String) = C1.this.x = x
}

Both setX1 and setX2 have the same effect, because C1.this is equivalent to this.

Inside a type body and outside a method definition, this refers to the type itself.

trait T1 {
  class C
  val c1 = new C
  val c2 = new this.C
}

The values c1 and c2 have the same type. The this in the expression this.C refers to the trait T1.

You can refer specifically to the parent of a type with super.

class C2 extends C1
class C3 extends C2 {
  def setX3(x:String) = super.setX1(x)
  def setX4(x:String) = C3.super.setX1(x)
  def setX5(x:String) = C3.super[C2].setX1(x)
}

C3.super is equivalent to super in this example. If you want to refer specifically to one of the parents of a type, you can qualify super with the type, as shown in setX5. This is particularly useful for the case where a type mixes in several traits, each of which overrides the same method. If you need access to one of the methods in a specific trait, you can qualify super. However, this qualification can’t refer to “grandparent” types.

What if you are calling super in a class with several mixins and it extends another type? To which type does super bind? Without the qualification, the rules of linearization determine the target of super (see the section called “Linearization of an Object’s Hierarchy” in Chapter 7, The Scala Object System).

Just as for this, you can use super to refer to the parent type in a type body outside a method.

class C4 {
  class C5
}
class C6 extends C4 {
  val c5a = new C5
  val c5b = new super.C5
}

Both c5a and c5b have the same type.

You can reach a nested type with a period-delimited path expression.

package P1 {
  object O1 {
    object O2 {
      val name = "name"
    }
  }
}
class C7 {
  val name = P1.O1.O2.name
}

C7.name uses a path to the name value in O2. The elements of a type path must be stable, which roughly means that all elements in the path must be packages, singleton objects, or type declarations that alias the same. The last element in the path can be a class or trait. See [ScalaSpec2009] for the details.

object O3 {
  object O4 {
    type t = java.io.File
    class C
    trait T
  }
  class C2 {
    type t = Int
  }
}
class C8 {
  type t1 = O3.O4.t
  type t2 = O3.O4.C
  type t3 = O3.O4.T
//  type t4 = O3.C2.t   // ERROR: C2 is not a "value" in O3
}

The conventional type ids we commonly use are called type designators.

class Person              // "Person" is a type designator.
object O { type t }       // "O" and "t" are type designators.
...

They are actually a short hand syntax for type projections, which we cover below.

A value of the form (x₁, … x_N) is a tuple value type.

When we create a type from a parameterized type, e.g., List[Int] and List[String] from List[A], the types List[Int] and List[String] are value types, because they are associated with declared values, e.g., val names = List[String]().

When we annotate a type, e.g., @serializable @cloneable class C(val x:String), the actual type includes the annotations.

A declaration of the form T₁ extends T₂ with T₃ { R }, where R is the refinement (body), declares a compound type. Any declarations in the refinement are part of the compound type definition. The notion of compound types accounts for the fact that not all types are named, since we can have anonymous types, such as this example scala session.

scala> val x = new T1 with T2 {
        type z = String
        val v: z = "Z"
}
x: java.lang.Object with T1 with T2{type z = String; def zv: this.z} =     $anon$1@9d9347d

Note that path-dependent type this.z in the output.

A particularly interesting case is a declaration of the form val x = new { R }, i.e., without any type ids. This is equivalent to val x = new AnyRef { R }.

Some parameterized types take two type arguments, e.g., scala.Either[+A,+B]. Scala allows you to declare instances of these types using an infix notation, e.g., a Either b. Consider the following script that uses +Either.

// code-examples/TypeSystem/valuetypes/infix-types-script.scala

def attempt(operation: => Boolean): Throwable Either Boolean = try {
  Right(operation)
} catch {
  case t: Throwable => Left(t)
}

println(attempt { throw new RuntimeException("Boo!") })
println(attempt { true })
println(attempt { false })

The attempt method will evaluate the call-by-value parameter operation and return its Boolean result, wrapped in a Right or any Throwable that is caught, wrapped in a Left. The script produces this output.

Left(java.lang.RuntimeException: Boo!)
Right(true)
Right(false)

Notice the declared return value, Throwable Either Boolean. It is identical to Either[Throwable, Boolean]. Recall from the section called “The Scala Type Hierarchy” that when using this exception-handling idiom with Either, it is conventional to use Left for the exception and Right for the normal return value.

The functions we have been writing are also typed. (T₁, T₂, … T_N) => R is the type for all functions that take N arguments and return a value of type R.

When there is only one argument, you can drop the parentheses, T => R. A Function that takes a call-by-name parameter (as discussed in Chapter 8, Functional Programming in Scala) has the type (=>T) => R. We used a call-by-name argument in our attempt example in the previous section.

Recall that everything in Scala is an object, even functions. The Scala library defines traits for each FunctionN, for N from 0 to 22, inclusive. Here, for example, is the version 2.7.5 source for scala.Function3, omitting most comments and a few other details that don’t concern us now.

// From Scala version 2.7.5: scala.Function3 (excerpt).
package scala

trait Function3[-T1, -T2, -T3, +R] extends AnyRef {
  def apply(v1:T1, v2:T2, v3:T3): R
  override def toString() = "<function>"

  /** f(x1,x2,x3)  == (f.curry)(x1)(x2)(x3)
   */
  def curry: T1 => T2 => T3 => R = {
    (x1: T1) => (x2: T2) => (x3: T3) => apply(x1,x2,x3)
  }
}

As we discussed in the section called “Variance Under Inheritance” above, The FunctionN traits are contravariant in the type parameters for the arguments and covariant in the return type parameter.

Recall that when you reference any object followed by an argument list, Scala calls the apply method on the object. In this way, any object with an apply method can also be considered a function, providing a nice symmetry with the object-oriented nature of Scala.

When you define a function value, the compiler instantiates the appropriate FunctionN object and uses your definition of the function as the body of apply.

// code-examples/TypeSystem/valuetypes/function-types-script.scala

val capitalizer = (s: String) => s.toUpperCase

val capitalizer2 = new Function1[String,String] {
  def apply(s: String) = s.toUpperCase
}

println( List("Programming", "Scala") map capitalizer)
println( List("Programming", "Scala") map capitalizer2)

The capitalizer and capitalizer2 function values are effectively the same, where the latter mimics the compiler’s output.

We discussed the curry method previously in the section called “Currying” in Chapter 8, Functional Programming in Scala. It returns a new function with N argument lists, each of which has a single argument taken from the original argument list of N arguments. Note that the same apply method is invoked.

// code-examples/TypeSystem/valuetypes/curried-function-script.scala

val f  = (x: Double, y: Double, z: Double) => x * y / z
val fc = f.curry

val answer1 = f(2., 5., 4.)
val answer2 = fc(2.)(5.)(4.)
println( answer1 + " == " + answer2 + "? " + (answer1 == answer2))

val fc1 = fc(2.)
val fc2 = fc1(5.)
val answer3 = fc2(4.)
println( answer3 + " == " + answer2 + "? " + (answer3 == answer2))

This script produces the following output.

2.5 == 2.5? true
2.5 == 2.5? true

In the first part of the script, we define a Function3 value f that does Double arithmetic. We create a new function value fc by currying f. Then we call both functions with the same arguments and print out the results. As expected, they both produce the same output. (There are no concerns about rounding errors in the comparison here; recall that both functions call the same apply method, so they must return the same value.)

In the second part of the script, we exploit the feature of curried functions that we can partially apply arguments, creating new functions, until we apply all the arguments. The example also helps us make sense of the declaration of curry in Function3.

Functions are right-associative, so a type T1 => T2 => T3 => R is equivalent to T1 => (T2 => (T3 => R)). We see this in the script. In the statement val fc1 = fc(2.), we call fc with just the first argument list (corresponding to T1 equals Double). It returns a new function of type T2 => (T3 => R) or Double => (Double => Double), in our case.

Next, in val fc2 = fc1(5.), we supply the second (T2) argument, returning a new function of type T3 => R, that is Double => Double. Finally, in val answer3 = fc2(4.) we supply the last argument to compute the value of type R, that is Double.

Finally, since functions are instances of traits, you can use the traits as parents of other types. In the Scala library, Seq[+A] is a subclass of PartialFunction[Int,A], which is a subclass of (Int) => A, i.e., Function1[Int,A].

Type projections are a way to refer to a type declaration nested in another type.

// code-examples/TypeSystem/valuetypes/type-projection-script.scala

trait T {
  type t <: AnyRef
}
class C1 extends T {
  type t = String
}
class C2 extends C1

val ic1: C1#t = "C1"
val ic2: C2#t = "C2"
println(ic1)
println(ic2)

Both C1#t and C2#t are String. You can also reference the abstract type T#t, but you can’t use it in a declaration because it is abstract.

If you have a value v of a subtype of AnyRef, including null, you can get its singleton type using the expression v.type. These expressions can be used as types in declarations. This feature is useful on rare occasions to work around the fact that types are path dependent, which we discussed in the section called “Path-Dependent Types” above. In these cases an object may have a path dependent type that appears to be incompatible with another path dependent type, when in fact they are compatible. Using the v.type expression retrieves the singleton type, a “unique” type that eliminates the path dependency. Two values v1 and v2 may have different path-dependent types, but they could have the same singleton type.

This example uses the singleton type for one value in a declaration of another.

class C {
  val x = "Cx"
}
val c = new C
val x: c.x.type = c.x