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.
I don’t recall hearing of the words “reify” or “reification” in my OOP years, but that may be because I studied aerospace engineering in college, not computer science. Since learning FP I often see those words, so I thought I’d try to understand their meaning.
The short answer is that the main definition seems to be:
“Taking an abstract concept and making it concrete.”
For the longer answer, I found the following definitions and examples of reification.
This is a page from my book, Functional Programming, Simplified
When I update the Scala Cookbook, I need to update Recipe 8.2, “How to use abstract and concrete fields in Scala traits.” That recipe is written particularly with an OOP developer in mind, and I didn’t write about handling the same situation from an FP perspective.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is a very short recipe, Recipe 8.2, “How to use abstract and concrete fields in Scala traits.”
You want to put abstract or concrete fields in your traits so they are declared in one place and available to all types that implement the trait.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 8.1, “How to use a Scala trait as an interface.”
You’re used to creating interfaces in other languages like Java and want to create something like that in Scala.
You can use a Scala
trait just like a Java
interface. As with interfaces, just declare the methods in your trait that you want extending classes to implement:
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 4.13, “How to define properties in an abstract base class or trait.”
You want to define abstract or concrete properties in an abstract base class (or trait) that can be referenced in all child classes.
This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 4.12, “When to use an abstract class in Scala.”
Scala has traits, and a trait is more flexible than an abstract class, so you wonder, “When should I use an abstract class?”
There are two main reasons to use an abstract class in Scala:
This page contains a collection of Scala
trait examples. I created many of these examples when I was writing the Scala Cookbook. Unlike the Cookbook, where I explain these examples in great detail, on this page I’m just sharing many of the examples so you can use this as a
trait reference page. (The Cookbook actually contains more examples than this page.)
Without any more introduction, here are the examples.
Summary: This article presents a discussion of the Template Method Pattern, using Java source code examples to explain it.
An abstract class in Java cannot be directly instantiated; only its subclasses can be instantiated.
An abstract class may contain zero or more abstract methods. An abstract method is not defined in the abstract class. Instead its signature is declared, but it has no body. The implementation is left to the subclasses that are created from this abstract class.
Here's an example of an abstract class definition: