case class

Debate about making Scala classes final by default 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.”

A little Scala `sed` class

A few times during the past year I got tired of trying to remember the Unix/Linux sed syntax while wanting to make edits to many files, so this weekend I wrote a little sed-like Scala class.

This is a page from my book, Functional Programming, Simplified

Appendix: Algebraic Data Types in Scala

Algebraic Data Type: “A type defined by providing several alternatives, each of which comes with its own constructor. It usually comes with a way to decompose the type through pattern matching. The concept is found in specification languages and functional programming languages. Algebraic data types can be emulated in Scala with case classes.”

From the Scala Glossary

Scala: Handling nested Options with flatMap and for

Summary: In this article I show a couple of ways to extract information from optional fields in your Scala domain models. This example is a little contrived, but if you have a situation where one Option instance contains one or more other Options, this article may be helpful.

There are times when you’re creating your domain model when it makes sense to use optional fields in your case classes. For instance, when you model an Address, the “second street address” isn’t needed for all people, so making it an optional field makes sense:

This is a page from my book, Functional Programming, Simplified

Scala/FP Idiom: Update as You Copy, Don’t Mutate

“I’ve been imitated so well I’ve heard people copy my mistakes.”

Jimi Hendrix


In functional programming you don’t modify (mutate) existing objects, you create new objects with updated fields based on existing objects. For instance, last year my niece’s name was “Emily Maness,” so I could have created a Person instance to represent her, like this:

A Quick Review of Scala’s Case Classes alvin May 30, 2017 - 6:46pm

“The biggest advantage of case classes is that they support pattern matching.”

Programming in Scala (Odersky, Spoon, and Venners)

How to create Scala object instances without using the “new” keyword (apply) alvin June 14, 2015 - 1:07pm

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 6.8, “How to create object instances without using the 'new' keyword.”


You’ve seen that Scala code looks cleaner when you don’t always have to use the new keyword to create a new instance of a class, like this:

val a = Array(Person("John"), Person("Paul"))

So you want to know how to write your code to make your classes work like this.

How to generate boilerplate code with Scala case classes alvin June 13, 2015 - 2:55pm

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 4.14, “How to generate boilerplate code with Scala case classes.”