If you define a case class, as we saw with Name
, you get pattern matching against the constructor for free. You should be using case classes to represent your data as much as possible, thus reducing the need to implement your own pattern matching. It is nevertheless useful to understand how pattern matching works.
When you create a case class, Scala automatically builds a companion object:
scala> case class Name(first: String, last: String) defined class Name scala> Name.<tab> apply asInstanceOf curried isInstanceOf toString tupled unapply
The method used (internally) for pattern matching is unapply
. This method takes, as argument, an object and returns Option[T],
where T
is a tuple of the values of the case class.
scala> val name = Name("Martin", "Odersky") name: Name = Name(Martin,Odersky) scala> Name.unapply(name) Option[(String, String)] = Some((Martin,Odersky))
The unapply
method is an extractor. It plays the opposite role of the constructor: it takes an object and extracts the list of parameters needed to construct that object. When you write val Name(firstName, lastName)
, or when you use Name
as a case in a match statement, Scala calls Name.unapply
on what you are matching against. A value of Some[(String, String)]
implies a pattern match, while a value of None
implies that the pattern fails.
To write custom extractors, you just need an object with an unapply
method. While unapply
normally resides in the companion object of a class that you are deconstructing, this need not be the case. In fact, it does not need to correspond to an existing class at all. For instance, let's define a NonZeroDouble
extractor that matches any non-zero double:
scala> object NonZeroDouble { def unapply(d:Double):Option[Double] = { if (d == 0.0) { None } else { Some(d) } } } defined object NonZeroDouble scala> val NonZeroDouble(denominator) = 5.5 denominator: Double = 5.5 scala> val NonZeroDouble(denominator) = 0.0 scala.MatchError: 0.0 (of class java.lang.Double) ... 43 elided
We defined an extractor for NonZeroDouble
, despite the absence of a corresponding NonZeroDouble
class.
This NonZeroDouble
extractor would be useful in a match object. For instance, let's define a safeDivision
function that returns a default value when the denominator is zero:
scala> def safeDivision(numerator:Double, denominator:Double, fallBack:Double) = denominator match { case NonZeroDouble(d) => numerator / d case _ => fallBack } safeDivision: (numerator: Double, denominator: Double, fallBack: Double)Double scala> safeDivision(5.0, 2.0, 100.0) Double = 2.5 scala> safeDivision(5.0, 0.0, 100.0) Double = 100.0
This is a trivial example because the NonZeroDouble.unapply
method is so simple, but you can hopefully see the usefulness and expressiveness, if we were to define a more complex test. Defining custom extractors lets you define powerful control flow constructs to leverage match
statements. More importantly, they enable the client using the extractors to think about control flow declaratively: the client can declare that they need a NonZeroDouble
, rather than instructing the compiler to check whether the value is zero.