SKB – Scala upper constraint

SKB – Scala upper constraint

Introduction

This article is part of the Scala knowledge bits Series.

Periodically, I will publish new exercises so you can slowly build up knowledge about Scala.

It is designed to be done in a very short amount of time and learn a little bit each day, just to create a routine.

This episode will teach you about Scala upper constraint.

Hope you are going to enjoy it! It is designed for anyone to learn Scala from scratch and slowly learn, one Bit at a time.

After this Bit, I would love to hear your feedback in the comments down below.

Feel free to join the Discord server as well if you would like some help and support from the rest of our community.

What are we learning today?

Today we are going to learn about Scala upper constraint !

Let’s go back to Object Oriented Programming concepts and specifically to interfaces (trait).

We are going to see how to constraint what type can be passed on. Several constraints are possible, let’s talk about a upper bound. The technical term for it is Upper Type Bounds but let’s keep it simple.

Time to try on the exercise on your own and scroll down for more information when you are done or if you are stuck.

Exercise

Here is an exercise to complete today.

If I did my job well, you should be able to guess by yourself the solution based on what you previously learned and based on the clues.

But if you get stuck, scroll down to get more information.

The goal of the exercise is to replace the ??? by a piece of code so that the exercise compiles and that’s how you win! Good luck!

You can fill the exercise right in here:

Or, if it does not load, go on to Scastie (wYG9m3B3T1qBOuvy5vLjAQ).

More information about Scala upper constraint

In this exercise you will learn (or have learned, if you have already solved the puzzle) about Scala upper constraint.

The new operator we are looking at today is <:

The syntax is A <: B and it means that the type A must be B or a class that has inherited from B, a child class.

The main advantage of doing this is that if you were to only have a simple generic class [A], you would not know anything about A at compile time. However, if you bound it, using [A <: B], the compiler would know that A is at least a B. That allow you to write code that can use the fields and methods of B as if A was B.

Extra note, when defining a custom type using type, it is possible to describe in a parent class as type MYTYPE <: CONSTRAINT so that child class has to implement it with a type that is a child of CONSTRAINT.

trait ParentClassOfConstraint

class ChildClassOfConstraint extends ParentClassOfConstraint

trait Foo {
   type MYTYPE <: ParentClassOfConstraint
}

class Bar extends Foo {
   override type MYTYPE = ChildClassOfConstraint
}

It is a bit advanced but I thought you should know about it.

Feel free to go back to the exercise, modify the code to try out new things and get a better intuition for Scala upper constraint.

Conclusion

I hope you have learned something new or had fun during this Scala Knowledge Bit.

Please ask questions or post feedback in the comments below.

Feel free to try on the next Scala Knowledege Bit.

If you are curious about the previous Scala knowledge Bits, go check it out! 🙂

Leave a Reply

%d bloggers like this: