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.

Tackling huge pull requests

Senjin Hajrulahovic — Wed, 11 May 2022 10:08:21 +0000

Bigger tasks require a lot of code changes, sometimes resulting in huge pull requests which are nearly impossible to review properly.

How can we mitigate that? The first thing which comes to mind is to not let it happen in the first place. How? By diving the task into smaller tasks and implement them step by step. Although preferable, this approach is not always possible.

A prime example for that is a major upgrade of a framework or a library which used all over the place. In case that upgrade happens to introduce a lot of breaking changes, it renders the aforementioned approach useless.

A solution for such a case is to structure your commits in a way that makes it easier to review. GitHub, for example, provides a feature which allows the reviewer to review the pull request commit by commit.

At first it sounds cumbersome, because in addition to the implementing the actual task you also have to keep in mind the way in which you commit your changes. Instead of committing you code at random, or event worse - not committing at all until your finished, you have to make your commits thoughtfully.

But this is actually an advantage if you look at it from the right angle. While this approach is definitely more demanding it has the advantage of forcing you to create a high level plan, to approach you task thoughtfully. This forces you to think of your implementation as a sequence of steps which you need to take to the solution. This prevents you to just start hacking away and finding yourself afterwards with a bunch of unrelated changed files, having a hard time coming up with a commit message.

You can even go step a further. You will probably agree that formatting changes can obfuscate the real changes that were made in order to accomplish the task at hand. In order to mitigate that we can make ourselves commit changes in formatting in separate commit. If we mark these commits as "formatting changes only" they can safely be ignored by the reviewer, and we will further ease the reviewing process.

Keep in mind that someone will eventually have to review the code you're writing and try to ease the work of the reviewer. The reviewer is you friend :)

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.

Tandem reading books - NoSQL

Senjin Hajrulahovic — Sun, 31 Oct 2021 18:03:38 +0000

Driven by the wish to explore the landscape of NoSql databases I decided to research the books available on the subject.

After browsing reviews and top lists of books on the subject I narrowed it down to these two books:

Seven Databases in Seven Weeks

NoSQL for Mere Mortals

Both of them cover all the mainstream database families. Namely relational, key-value, columnar, graph and document databases.

Unable to decide which one to pick I decided to read them both. Back to back... to back.

Although I was initially put of by the title of the second one I still decided to read it despite not being a mere mortal.

"Seven Databases in Seven Weeks" is basically a collection of quickstart guides for one NoSql database per database family. It goes less into concepts and focuses more on implementation. After each chapter you will have a functioning example of simple database interactions with the database in question. The book does not shy away from using databases which are exclusively available through cloud providers. After completing one of the chapters you'll have a working DynamoDB instance hosted on AWS.

NoSQL for mere mortals, on the other hand, goes a lot deeper regarding motivation and limitations of each database family. It mostly stays database agnostic and focuses on guiding you through the concepts which are driving the design and behavior of the database families in question. Although it does not contain code it presents use cases for all the NoSql database families and provides conceptual solutions for them.

Prior to reading these books I was highly biased towards relation databases. Although I worked with MongoDB and Redis, most of the time I work with relational databases like PostgreSQL and MySQL. The idea that you have to do additional work up front but reap the rewards later suited me. Benefits like enforced data integrity with schema and foreign keys, transactions, "easy" querying and so forth.

Reading these books did not change my preconceived notion that much. NoSql database can be vary useful for specific tasks which fit the database model. It is of utmost importance to truly accept and embrace a particular NoSql database and its concepts. If you try to mimic the relational model in any of these database you'll have a bad time.

But one has to admit that one of the things in which NoSql databases are far ahead of relational databases is distributability. A lot of NoSql databases are build from the ground up with distributability in mind.

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.