Traits are better than Legos!

One of the most powerful (and cool) features in Scala is that you can use traits as stackable modifications.
Let’s see how it works with a simple tutorial 🙂

Our goal is to create a list of ordered colours, let’s call it ColourMixer. First we create a class to represent what a basic (empty) colour mixer is:

class ColourMixer {
   def colours: List[String] = List();
   override def toString = colours mkString ", "
}

Let’s create our Legos blocks!

trait Red extends ColourMixer { 
	abstract override def colours = "red" :: super.colours 
}

trait Green extends ColourMixer { 
	abstract override def colours = "green" :: super.colours 
}

trait Blue extends ColourMixer { 
	abstract override def colours = "blue" :: super.colours 
}

…wait a second! Are we abstracting a concrete method???
Traits are dynamically bound, while classes are statically bound: classes select a specific implementation according to the declared type, instead traits do it at runtime. Because of this property, we cannot say what implementation super is referring to — that’s why the abstract keyword is appropriate here. We will be able to decide only at runtime…and that’s why we can now play Legos!

val bgr = new ColourMixer with Red with Green with Blue
println(s"BGR: $bgr") // it prints: "BGR: blue, green, red";

val rgb = new ColourMixer with Blue with Green with Red
println(s"RGB: $rgb") // it prints: "RGB: red, green, blue"

Note that the application order is usually from the last to the first trait.

How cool is that! 😀

To Feature Branch or Not to Feature Branch?

Even when working with Agile methodologies and a Continuous Integration pipeline, some developers love feature branching – and they complain a lot when they are forbidden from using it!
The arguments in its favour are usually:
– “It makes easy to code review”
– “I can focus on my task and worry about conflicts later”
– “No feature branching means no code reviews. We will drop our code quality!”

Let’s discuss them 🙂

“It makes easy to code review”

Code reviews are essential in the team to ensure high quality and a consistent style in the code. Although it’s true that branches make easy to create pull requests, they are not the only way to review the code. I personally prefer to have a team meeting where all the commits are discussed all together face-to-face. There are several benefits in this approach:
– Misunderstandings are reduced – no more long cold threads comments arguing!
– Less experienced team members can learn from the most experienced ones.
– The team can discuss (and change if needed!) its guidelines and style when needed.

Unfortunately, there are some disadvantages as well:
– Meetings are time consuming and they need to be properly organised.
– Each developer needs to read the code to review before the meeting to build some basic understanding of it: again, discipline and time needed!

“I can focus on my task and worry about conflicts later”

Feature branching delays conflicts, doesn’t make them disappear! This is against the continuous integration methodology: it is better to discover conflicts as soon as we create them rather than on a Friday afternoon at 16.00 with the release scheduled on Monday at 11.00 (yes, it happened 😐 )

“We will drop our code quality!”

Actually, it’s the opposite! Feature branching discourages refactoring to avoid the generation of conflicts – if you ever had to deal with git conflict you know what I am talking about!