Exploring Type class in Scala: Conclusion

I remember watching Dan Rosen's excellent video tutorial on Type class in Scala, earlier this year. And I remember understanding what he was saying, but yet, I was not sure If I grokked the concept he was trying to explain.

I understood all the code snippets, I could follow along with the examples but yet I was not sure I was getting it. I could not really appreciate the rationale, it felt as if I was rote learning and after watching that video tutorial, I was not sure if I could think in type classes.

Moreover, the whole machinery he was describing just felt way too verbose. And this feeling was not just exclusive to the video, it was how I felt about almost every blog post on type class in Scala back then.

I have since then realized why I felt this way: I was working with the wrong mental model.

Three Real-world examples of Type class pattern in Scala

In this post, we are going to look at a couple of examples where the type class pattern has been put to use in Scala. This is the sixth post in a series of posts on the Type classes pattern.

This post assumes an understanding of main concepts and terms that come into play when encoding the type class pattern in Scala. If you are new to how type classes are encoded in Scala, then I advise to first read the previous posts in this series. You can do that by starting from the introductory post: Exploring Typeclass in Scala: A knowledge pack

That being said, let us now go ahead and explore 3 examples of the Type class pattern being used in Scala. We start with JSON serialization in the Play Framework.

Common forms of Type class pattern in Scala

This post will explore some of the various forms the type class encoding in Scala can take.

It is the 5th post in a series of posts on type class encoding in Scala. Check the introductory post: Exploring Typeclass in Scala: A knowledge pack, if you want to start reading the series from the beginning.

Typeclass is not a native language feature but a pattern in Scala, which might make it hard to easily spot when used in a codebase. To add to this confusion, there could also be slight variations to the approach taken to encode the pattern in Scala.

Encoding Type class in Scala

This post looks into how to encode the Type class pattern in Scala. It is the fourth post in the Type-class knowledge pack series.

The previous posts in this series covered the various language features of Scala that needs to be understood before approaching how to encode the Type class pattern.  As previously explained, Type class is not a native language features in Scala; it is a pattern that uses other native language features. Thus to be able to reason along with how the Type class is encoded, a good working knowledge of the main language feature that comes into play when encoding the pattern is needed.

Exploring Type Annotations in Scala

Do you come across code like this in Scala: def apply[T <% Mappable[T]](x: T): T or class ReferenceQueue[+T <: AnyRef] { .. } or def setValue[T1 >: T](value: T1): T? code that when you try to decipher, it always seems your brain grinds to a halt and fails to parse what it is seeing? At which point you silently go beserk and swear at this crazy thing called "Scala"?

Ok, take a deep breath. This post is for you. It will teach you what you need to know in other to be able to read and demystify such incantations. A skill that would come in handy when encoding or when reading code that uses Type classes in Scala.

This post is the 3rd post in the Typeclass knowledge pack series. It will take a brief look at types, type constructors, type parameters and the type annotations.

Implicit Scope and Implicit Resolution in Scala

Having a good understanding of implicits is necessary to fully appreciating how the type-class pattern is encoded in Scala.

This is because implicit is one of the core language features of Scala that makes it possible to encode the type-class pattern.

This post would, therefore, explore implicit in Scala with a focus on implicit resolution. It is the second post in the Type class knowledge pack series.

Revisiting Polymorphism: It is more than Inheritance and Subtyping

This post is part of the Type class knowledge pack series in which I explore the pattern for encoding Type classes in Scala. This post will be about polymorphism.

But why Polymorphism you might ask? isn't this series about the Type class pattern? Why do we have a single post dedicated to Polymorphism?

As it turned out, the type class pattern is really just one approach to writing polymorphic code.

And from experience, having a more in-depth appreciation for what Polymorphism is, will go a long way in understanding the why and how of the Type class pattern: which is why, before I go into the actual mechanism of encoding the Type class pattern in Scala, I think it will be of utmost benefit to first explore polymorphism.

Exploring Type class in Scala: A knowledge pack

This series of blog post seeks to provide an exhaustive exploration of the Type-class pattern in Scala.

Aptly described as a "knowledge pack", it won't only touch on the actual mechanism of encoding the type-class pattern in Scala, but it will also explore a bit of the underlining idea behind the pattern and the various language features that come together to make it possible to encode it the way it is done in Scala.

The reason for taking this approach is borne out of my own experience while trying to grok the concept.

I quickly discovered, as anybody new to Scala will do, that the idea of Type classes is widely used in Scala: both in the standard library and in popular third-party libraries. Thus it is imperative to have a good working knowledge of how it works, to be able to effectively use/read code/libraries that make use of the pattern.