Typically, a trait defines a general behavior or a general feature that may be added to a new class when the class is defined. A useful trait is one that might apply to many different, usually unrelated, classes. Inheriting from a mixin is not a form of specialization but is rather a means of incorporating some new functionality. So, the role of a trait is quite different form the role of an abstract class.

We know how to define a new concrete subclass B that extends an existing superclass A. But the new features in the subclass B cannot be reused to extend a different superclass than A. A trail is a generic subclass that in parametrized in its superclass, and therefore can be reused to extend different superclasses.

A trait contains:

• Some deferred methods that the client class must provide - these are the requirements of the trait;
• Some other methods that are implemented using the deferred methods and that become available to the client class - this is what that trait provides to the client class.

Interfaces in Java solve the problems of subtyping and conceptual modeling within the context of single inheritance, but does not allow code reuse. Traits allow code reuse and, at the same time, avoid the many problems of multiple inheritance.

A class can incorporate multiple traits using the with keyword, accumulating their implementations. Example:

class SuperCar extends Car with Flying with Diving

The traits can also be mixed-in when creating a new object. Example:

val supercar = new Car with Flying with Diving

Another example: we can add comparison operators to our Point3 class by mixing-in the predefined trait Ordered, as follows:

class Point3(xc: Int, yc: Int, zc: Int) extends Point2(xc, yc) with Ordered[Point3] {
    def compare(that: Point3) = { ... }
    ...
}

trait Ordered[A] {
// requires
    def compare(that: A): Int
// provides
    def <  (that: A): Boolean = (this compare that) <  0
    def >  (that: A): Boolean = (this compare that) >  0
    def <= (that: A): Boolean = (this compare that) <= 0
    def >= (that: A): Boolean = (this compare that) >= 0
    def compareTo(that: A): Int = compare(that)
}

scala> trait T {
        def f = { println("T") }
    }
defined trait T

scala> trait A extends T {
        override def f = { println("A") ; super.f }
    }  
defined trait A

scala> trait B extends T {
        override def f = { println("B") ; super.f }
    }
defined trait B

scala> (new AnyRef with A with B).f
B
A
T

scala> (new AnyRef with B with A).f
A
B
T

Systems of classes versus Algebraic data types

abstract class Expr {
  def eval: Int
}
class Number(n: Int) extends Expr {
  def eval: Int = n
}
class Sum(e1: Expr, e2: Expr) extends Expr {
  def eval: Int = e1.eval + e2.eval
}

But if the types of the data don't change and we want to build systems that should be extensible with new operations, be better approach is to use the old idea of algebraic data types, with the associated notions of constructor and pattern matching (a selection and decomposition mechanism).

Scala supports directly the idea of algebraic data types via the notion of case class. Example:

abstract class Expr
case class Number(n: Int) extends Expr
case class Sum(e1: Expr, e2: Expr) extends Expr

def eval(e: Expr): Int = e match {
  case Number(x) => x
  case Sum(l, r) => eval(l) + eval(r)
}

abstract class Expr {
  def eval: Int = this match {
    case Number(n) => n
    case Sum(e1, e2) => e1.eval + e2.eval
  }
}
case class Number(n: Int) extends Expr
case class Sum(e1: Expr, e2: Expr) extends Expr

Effects of declaring a case class

1. A constructor global function with the name of the class is automatic generated - this enables the creation of instances of the class without using the new operator;
2. The following methods are redefined for the class at hand: toString, equals, hashCode;
3. Accessors methods to the arguments of the constructor are generated;
4. The language of the patterns are extended to include the one new pattern for each class.

Implementing pattern matching