What def, val, and var fields in Scala traits look like after they’re compiled (including the classes that extend them)
I generally have a pretty good feel for how Scala traits work, and how they can be used for different needs. As one example, a few years ago I learned that it’s best to define abstract fields in traits using
def. But there are still a few things I wonder about.
Today I had a few free moments and I decided to look at what happens under the covers when you use
var fields in traits, and then mix-in or extend those traits with classes. So I created some examples, compiled them with
scalac -Xprint:all, and then decompiled them with JAD to see what everything looks like under the covers.
I was initially going to write a summary here, but if you want to know how things work under the hood, I think it helps to work through the examples, so for today I’ll leave that as an exercise for the reader.
As a brief note today, here’s an example of stackable modifications in Scala.
What is ‘super’ in Scala when you mix in traits?
Lately I was curious about what
super means when you mix Scala traits into a class or object. A simplified answer is that
super refers to the last trait that’s mixed in, though I should be careful and note that this is an oversimplification.
This can be demonstrated in an example that uses both inheritance and mixins with traits. Given this combination of traits and classes:
Here are a few notes about using Scala traits as mixins, specifically:
- The order in which mixed-in traits are constructed
- The order in which overridden methods in traits are called when multiple traits are mixed in