class

A Scala Factory Pattern example

Here’s a small example of how to create a Factory Pattern in Scala. In the Scala Cookbook I created what some people might call a simple factory and/or static factory, so the following code is a much better implementation of a true OOP Factory Pattern.

The factory classes

I don’t have too much time to explain the code today, but here are the classes that make up the factory, including a set of “animal” classes along with a DogFactory and CatFactory that extend an AnimalFactory trait:

How to disassemble and decompile Scala code (javap, scalac, jad)

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 14.6, “How to disassemble and decompile Scala code.”

Problem: In the process of learning Scala, or trying to understand a particular problem, you want to examine the source code and bytecode the Scala compiler generates from your original source code.

Solution: You can use several different approaches to see how your Scala source code is translated:

GraalVM native executables can run faster than Scala/Java/JVM applications, with much less memory consumption

In two small tests where GraalVM was able to create a native executable, the native executable ran significantly faster than the equivalent Scala/Java code running with the Java 8 JVM, and also reduced RAM consumption by a whopping 98% in a long-running example. On the negative side, GraalVM currently doesn’t seem to work with Swing applications.

Dream of the night sky and a distance classroom

Had a fun dream overnight. At first I was laying here in my bed and having a hard time falling asleep, but at some point it switched to me laying on the floor, in the living room area but near the kitchen. Someone was in the kitchen, but it’s twelve hours later now and I can’t remember who. For a long time I laid there uncomfortably, thinking I was awake, but I was only awake in a lucid dream.

Then I felt the usual sensation that’s hard to describe — like you can feel that something is about to happen — and I was pulled away and out through the front wall of the apartment. I was flying, or at least levitating, looking up at the night sky. It was beautiful, and I could have stayed there for a long time.

Then I was pulled away again, eventually approached a tree, and then landed. Wherever this was, there was a building, and a number of other people were also arriving at the same time. We went inside, and a slightly older woman was trying to usher us into a room. It felt like it was some sort of classroom and she was going to teach us something.

Unfortunately I was rapidly whisked away and woke up in my bed. It was all a good time, but seeing the night sky like that was particularly amazing.

What def, val, and var fields in Scala traits look like after they’re compiled (including the classes that extend them)

Table of Contents1 - def field in trait2 - val field in trait (abstract)3 - val field in trait (concrete)4 - var field in trait (abstract)5 - var field in trait (concrete)6 - An abstract class in the middle7 - A trait in the middle8 - Summary

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 def, val, and 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.

An example of stackable modifications in Scala

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:

A good reason to use sealed traits and classes in Scala

This scala-lang.org documentation page shares a good reason to use “sealed” traits and classes: When you created sealed traits, the compiler can easily tell all of the subtypes of your class or trait, and as just one benefit, you don’t need to add a default, “catch-all” case in your Scala match expressions.

Debate about making Scala classes final by default

contributors.scala-lang.org has become my favorite website this past week. It’s very interesting to read through the debates about new language features for Scala 3 (Dotty). For instance, in the Make concrete classes final by default discussion I think everyone agrees they wish they had gone that way with Scala 2, but it would cause too many problems if they tried to make this a new standard in Scala 3. The discussion — in addition to reading Effective Java — makes me wish I had used final before all of my classes.

In another discussion titled, Why does Scala need its own build tool (SBT), someone makes a claim that Martin Odersky and his team created SBT as a build tool solution, and Mr. Odersky replies, “Definitely not my answer. I was always very skeptical of SBT’s approach and remain so.”