def

Explaining Scala’s `val` function syntax

This is an excerpt from my book on Functional Programming in Scala. It’s an appendix that “explains and explores” Scala’s function syntax.

Background

I wrote in the “Functions are Values” lesson that most developers prefer to use the def syntax to define methods — as opposed to writing functions using val — because they find the method syntax easier to read than the function syntax. When you write methods, you let the compiler convert them into functions with its built-in “Eta Expansion” capability. There’s nothing wrong with this. Speaking as someone who used Java for 15+ years, the def syntax was easier for me to read at first, and I still use it a lot.

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.

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

On Using `def` vs `val` To Define Abstract Members in Scala Traits

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.

LOGO used “TO” like Scala and Ruby use “def”

I ran across the following page in the book Clean Code, and it really caught my attention. In short, there is a programming language named LOGO that apparently used to keyword TO in the same way languages like Scala and Ruby use “def.” This is described near the bottom of the page in the following image, in the area I highlighted:

Clean Code - The TO keyword in the LOGO programming language

I’ve never used LOGO, but that sounds like a clever approach, and since I ran across this discussion, I have to say, it’s had an effect on my methods. Every time I type “def,” I think “TO,” and it makes me think a little bit more about how I want to write my method.

For more information on book, check out the Clean Code book.

Scala: Reassignable variables and properties (def fields)

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.”:

Scala: How to add new methods to existing classes

Update: This article was written for Scala 2.9. Things changed a little bit in Scala 2.10, so see this new article, Creating implicit methods in Scala 2.10, for correct examples for 2.10 and newer versions of Scala.

A cool thing about implicit conversions in Scala is that they let you add new methods to existing classes, including existing Java and Scala classes such as String, File, and so on.