Guide of deriving Type Class methods for Case Classes
Scala developers might reach a point when they think the language is not letting them make the code more DRY(Don’t Repeat Yourself) and they have to drop their domain language and start using Factories and Builders or other ambiguous concepts. They end up copy-pasting some trivial boilerplate code around, or in some cases, go to the dark side and write macros that would generate the code for them and thus reduce the maintainability of the code. To work around this problem we can use 2 powerful concepts: Implicit Induction and Type Class Pattern.
Induction
In Mathematics we can represent a natural number using Peano numbers. This can be done, by first defining a concept of 0 and a successor(n + 1). By using mathematical induction method, the 0 would be the base case and successor would be the induction step. In programming we can express similar concepts using pattern matching:
Type Class Pattern
In recent years in Scala, as well as in other programming languages, there was an emergency of Type Class Pattern, that was initially introduced in Haskell. The basis is really similar to the notion of working only via Interfaces but provides the ability to express ad-hoc polymorphism.
Derivable Ordering for Nested Tuples
Let’s create a Type Class for Ordering and use Induction to derive instances for a nested tuple.
By having instances for basic types, we first create an instance without using Induction so we can work out the basic wiring.
Now if we choose a tuple structure, that would let us check the first element of the tuple and treat the second element of the tuple as something that can be Ordered, we should be able to use induction. If we choose a structure like (a, (b, (c, d))), we can start using induction. Where simple type that we described before like Int or String is the base case and matching tuple is the inductive step(Just like the Induction example above).
Derivable Ordering for Case Classes
When working with Type Classes it’s quite common to write Type Class instances for each of your Case Classes. As mentioned before it can get tedious and boring and you might end up reaching for macros(I am not saying that it’s bad to write macros, just that you pay the cost of maintaining them). Let’s use Shapeless and it’s HList (heterogeneous list / or in other words, list of many types, that has type safety) to resolve this problem. First, we need to understand that any Case Class can be represented as an HList. For example case class Person(name: String) can be represented as HList (String :: HNil). So the first problem we need to solve is how to derive instances for any HList.
Now we need to transform each Case Class to an HList and we can automatically derive Type Class instances by having primitive instances:
Transforming Between CaseClasses (Bonus)
If any Case Class can be represented by an HList it should be trivial to transform between Case Classes.
Summary
When working with Scala functions modeling your system boundaries via interfaces(traits) can provide you with an additional benefit of providing code derivability. You can provide good derivability by creating primitive instances for your Type Classes and by doing so, you can make other fellow developers incorporate your library much easier and your domain much clearer. For example, expressing the bridge between domains with Transformable Type Class.
References
This post was inspired by:
- https://www.youtube.com/watch?v=CstiIq4imWM Aaron Levin
- https://www.youtube.com/watch?v=Nm4OIhjjA2o Aaron Levin
- https://www.youtube.com/watch?v=auaT2Ft65Qo Thurston Sandberg
Additional resources:
- You can try out the code described in this post here
- If you don’t have Scala on your machine, just use Binder instead
- https://github.com/milessabin/shapeless
