Type classes in Scala are one of those scary concepts to be used only by the cognoscenti, right? Well, no, actually. In reality, they are quite simple.
As usual, Daniel Westheide has some good things to say in his Neophyte's Guide to Scala. Because his explanation is so good, I won't go into as much detail here as I might otherwise.
The somewhat confusingly-named Type Class is really just a different sort of trait.
If we have a Type Class "C" and a type "T" which is a member of "C", then "T" is required to implement the operations that "C" requires. But unlike the relationship between a trait and its implementations which is based on the polymorphism inherent in object-oriented programming, the relationship between a type class and its members is more ad hoc and, in practice, relies on the "implicits" mechanism of Scala.
The two most commonly encountered type classes in Scala are Numeric and Ordering. Since Numeric extends Ordering, I'll just show a typical usage of Ordering.
The SeqLike trait (extended by all the familiar sequence-type collections)
defines a sort method which takes an implicit parameter which is an Ordering.
If that parameter is available, it will be used to define the ordering for the sort. If you write the following Scala code, the result will be a properly sorted list:
val a = List(10, 5, 8, 1, 7).sorted
You don't have to provide the ordering parameter:
it is defined for you, although you're free to pass an explicit orderer of course.
This is all part of the magic of implicits, which I don't have space to go into here.
So, let's look at a practical example of a type class.
I was working on a rule parser.
This reads rules (as Strings) in the form of, for instance,
feels cold: t < 0 or t < 5 and w > 10
where, in this case, t is temperature (in Celsius) and
w is wind speed in km/h.
But you will notice that I haven't yet specified whether the calculations should be
performed with Int or Double (or whatever).
We might also have rules that are purely textual,
perhaps based on dictionary order or something like that.
So, it would be inappropriate to parse these rules as, for instance, being based on Double.
I therefore set out to parse the rules in String form and then (and only then) convert them into numeric rules.
Then I ran into a snag.
The Numeric type class, which extends Ordering, isn't quite powerful enough to
do everything I needed.
In particular, I needed to be able to take a String and convert it into my generic type.
I tried everything I could think of including, obviously, extending Numeric.
Finally, I turned to StackOverflow. The answer was so simple:
instead of trying to extend the Numeric type class, I should simply create my own.
Until that moment, I hadn't really grasped the amazing flexibility of type classes.
Unlike in Java where the various numeric types all extend the abstract class Numeric (a totally inadequate way of doing things by the way),
in Scala, the numeric types such as Int do not have to extend anything.
Instead, a programmer can simply create a type class,
adding members that implement the operations for any given type, for example, Int or Double.
This is the origin of the name "type class".
So, to cut a long story short, I created my own type class Valuable, which you can see in
the answer to the StackOverflow question.
Actually, I ended up adding a few more operations (why not?) and was able to complete my rule parser.
The direct result of parsing a rule is a RuleLike object. RuleLike is a trait that extends AnyRef and has one method signature:
def asRule: Rule[String]
Rule[T] is trait which is defined thus:
sealed trait Rule[T] extends (() => Try[Boolean])
and has a transform method (like map but takes two functions) such that we can transform a Rule[String] into, say, a Rule[Int] (with the help of a lookup function to evaluate variable).
If you're interested in seeing the whole code base for the rule parser, you can find it here.
