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 part of the illness stuff I went through in 2014-2016, I have absolutely no memory of creating this Scala/FP “I can’t believe I used a
var” image, but as I just ran across it while working on this website, I thought it was funny. Apparently I created it when I was writing about How to create outlined text using Gimp. (I do remember that someone else created an image of Martin Odersky with the same phrase.)
This is a page from my book, Functional Programming, Simplified
“A variable is a named entity that refers to an object. A variable is either a
val or a
var. Both vals and vars must be initialized when defined, but only vars can be later reassigned to refer to a different object.”
Sadly, I had to get away from Scala for a while, but now I can get back to it again. Just as I started getting back into it I happened upon the following code, and thought, “Well, surely
title in this anonymous class is a
var field. How strange that the Programming in Scala guys would use a
var like this.”:
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is a short recipe, Recipe 4.9, “How to set uninitialize var field types in Scala.”
You want to set the type for an uninitialized
var field in a Scala class, so you begin to write code like this:
var x =
and then wonder how to finish writing the expression.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 4.7, “How to prevent getter and setter methods from being generated in Scala classes.”
When you define a class field as a
var, Scala automatically generates getter and setter methods for the field, and defining a field as a
val automatically generates a getter method, but you don’t want either a getter or setter.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 4.2, “How to control the visibility of Scala class constructor fields.”
You want to control the visibility of fields that are used as constructor parameters in a Scala class.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 3.17, “How to declare a variable (var) before using it in try/catch/finally.”
You want to use an object in a
try block, and need to access it in the
finally portion of the block, such as when you need to call a
close method on an object.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is one of the shortest recipes, Recipe 3.9, “How to assign the result of a match expression to a variable.”
You want to return a value from a
match expression and assign it to a variable, or use a
match expression as the body of a method.
This is an excerpt from the Scala Cookbook (partially re-worded for the internet). This is Recipe 10.6, “Understanding Mutable Variables with Immutable Collections.”
You may have seen that mixing a mutable variable (
var) with an immutable collection causes surprising behavior. For instance, when you create an immutable
Vector as a
var, it appears you can somehow add new elements to it: