DEV Community: Senjin Hajrulahovic

Typeclasses explained in Java

Senjin Hajrulahovic — Wed, 27 Jul 2022 12:28:43 +0000

By definition type classes are a type system construct that supports ad hoc polymorphism.

Let us elaborate this definition by explaining following aspects of type classes:

Externalized not implemented inside the class in question
Classes which we do not control
Possibility to have multiple implementations
Lawfullness

An excellent example for showcasing the aforementioned aspects and the differences between the type class approach opposed to the usual inheritance approach are the java interfaces Comparable and Comparator.

External vs internal implementation

In order to use inheritance approach the class which instances we want compare has to extend Comparable and add an implementation for the compareTo method. Opposite to that if we take the type class approach we will implement a Comparator instance.

Classes which we do not control

It's not possible to use the inheritance approach in cases in which we do not have control over the class we want to compare. E.g. the class is pulled from an external dependency.
There are way around that, e.g. defining a wrapper class which can sometimes be inconvenient. The type class approach does not have that restriction. We are free to implement Comparator instance for every class we can our hands on.

Single vs multiple implementations

Using Comparable restricts us to a single Comparable implementation. There are ways around that too, e.g using subclasses and define different implementation for each subclass. Depending on the language we use we can define one or more type class implementations. While scala allows multiple type class implementations, expected they are not defined at the same resolution level. You can read more about it here. Haskell usually does not allow multiple type class instances. Although there are ways to avoid this restriction.

Lawfullness

Every type class comes with a set of laws which every instance needs to abide to. In case of the Comparator type class we have e.g.:

if x.equals(y) then x.compareTo(y) == 0

if x.compareTo(y) == 0 then y.compareTo(x) == 0

if x.compareTo(y) < 0 and y.compareTo(z) < 0
then x.comapreTo(z) < 0

In general this is all there is to type classes. While this is just an example there is a plethora of type classes most of which come from category theory. But you definitely don't need to go into that topic to make use of them. In scala type classes are implemented using traits which are quite close to java interfaces.

When it comes to scalas implementation of type classes the part that confuses people the most seems not to be the actual concept of type classes but the scala implicits magic behind the scenes. The magic is required because, different from haskell which defines type classes as first-class structure
In scala they are not part of the language core, instead they are implemented using other language features such as implicit parameters and implicit conversions. Implicits can sometimes be confusing especially for newcomers, but don't let yourself get discouraged.

As a result the notion of comparing instance of a certain class is externalized. Method definitions using the inheritance approach would look this this:

// java
public <A extends Comparable<A>> ResultType methodWhichNeedsToCompareInstances(A a)

// scala
def methodWhichNeedsToCompareInstances[A <: Comparable[A]](a: A): ResultType

While using the type class approach they would look like this:

// java
public <A> ResultType methodWhichNeedsToCompareInstances(A a)(Comparator<A> comparator)

// scala
def methodWhichNeedsToCompareInstances[A](a: A)
(implicit comparator: Comparator[A]): ResultType

If I managed to gain you interest you can take a look at one of the following libraries like cats, scalaz for scala and vavr for java which contain type class definitions and implementations for common types.

Utilizing Scala Cats to improve database access code

Senjin Hajrulahovic — Wed, 23 Mar 2022 10:36:32 +0000

Let start with something familiar. If you worked with scala for some time you most likely came across scala.concurrent.Future#sequence and scala.concurrent.Future#traverse.

Here is a simplified method signature of these two methods:

def traverse[A, B](items: Seq[A])(f: A => Future[B]): Future[Seq[B]]
def sequence[A](items: Seq[Future[A]]): Future[Seq[A]]

cats.Traverse is an abstraction which embodies the operation scala.concurrent.Future#traverse but is more general. Since in addition to the function argument type A and return type B, the context type of both Seq and Future are further generalized:

trait Traverse[F[_]] {
  def traverse[G[_], A, B](fa: F[A])(f: A => G[B]): G[F[B]]
}

If you're using a newer version of slick for database access you're most likely familiar with DBIO. There are often cases when you have a collection of some sort and want to execute a database action for each of the elements in the collection.
Since DBIO is somewhat similar to Future we could write:

def f[A](a:A): DBIO[B] = ???

val b: DBIO[Seq[B]] = DBIO.sequence(items.map(f))

or if we lack documentation awareness we could event end up writing:

items.foldLeft(DBIO.successful(Seq()) {
  (acc, next) => acc.flatMap(a => f(next).map(i => acc :+ i)
}

But if we utilize slickcats we can simply write:

items.traverse(f)

But if you try to use this approach without the proper dependencies you'll see that the compilers complains about missing implicit instances for DBIO.

In order to fix that you have to add following dependency:
https://github.com/RMSone/slick-cats
and add following import to your class:

import com.rms.miu.slickcats.DBIOInstances._

Depending on how far you are in you functional programming journey you'll know that cats.Traverse is a special kind of functor which requires a type constructor with a single type argument.

If the methods you want to use together with slickcats return DBIOAction[+R, +S <: NoStream, -E <: Effect] or some other related type which has more than one type parameter the compiler will complain. In these situation you'll have to help the compiler a bit by either changing the method signature to DBIO or you'll have to cast it to DBIO explicitly.

This is just an example. slickcats has typeclass instances which can help you to write more readable database access code.

Mocking scala method calls containing type parameters with context bounds

Senjin Hajrulahovic — Sat, 16 Oct 2021 10:33:03 +0000

In our example we will be looking at a very simple auditing mechanism. Every time a resource changes we want to store its previous and its new state as json.

While investigating the code base we come across a trait like this:

trait AuditLogHandler {
    def addAuditLog[A: Writes](previous: A, next: A)
            (implicit session: Session): Unit
}

We find out that Writes is needed to create the json form of the object, and we notice that Session takes care of actually storing the values in the database.

After creating a class which utilizes an instance of the trait above we start to write tests. We decide to use mocking.

Our first attempt to mock the addAuditLog method will most likely look like this:

(auditLogHandler.addAuditLog(_: A,_: A)(_: Session))
    .expects(*, *, *).anyNumberOfTimes().returning(())

which will result in the error message:

Unspecified value parameters: session: Session

We scratch our heads in disbelief. How can it be unspecified if it is right there?! We think that our IDE got confused, which happens from time to time. So we decide to recompile it with sbt which gives us the same error.

After spending some time looking up the issue without results we analyze our dependencies. Their versions seem to be quite behind. Full of hope we update scalatest and other related dependencies just to see the same outcome.

Still:

Unspecified value parameters: session: Session

Hopefully we eventually remember that A: Writes is just syntactic sugar for an implicit parameter of type Writes[A].

So:

def addAuditLog[A: Writes](previous: A, next: A)
        (implicit session: Session): Unit

is actually:

def addAuditLog[A](previous: A, next: A)
        (implicit writes: Writes[A], session: Session): Unit

After trying it out it proves to be the solution:

(auditLogHandler.addAuditLog(_: A, _: A)
    (_: Writes[Assembly], _: Session))
    .expects(*, *, *).anyNumberOfTimes().returning(())

Looking at the solution we can't help but feel a bit irritated that it took us that much to figure out, while still being happy that we actually got it to work in the end.