How to force calling methods to leave parentheses off accessor (getter) methods

By Alvin Alexander. Last updated: December 7, 2021

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 5.6, “How to force calling methods to leave parentheses off accessor (getter) methods.”

Problem

You want to enforce a Scala coding style where getter/accessor methods can’t have parentheses when they are invoked.

Solution

Define your getter/accessor method without parentheses after the method name:

class Pizza {
    // no parentheses after crustSize
    def crustSize = 12
}

This forces consumers of your class to call crustSize without parentheses:

scala> val p = new Pizza
p: Pizza = Pizza@3a3e8692
// this fails because of the parentheses

scala> p.crustSize()
<console>:10: error: Int does not take parameters
              p.crustSize()
                            ^
// this works
scala> p.crustSize
res0: Int = 12

Coming from a Java background, I originally named this method getCrustSize, but the Scala convention is to drop “get” from methods like this, hence the method name crustSize.

Discussion

The recommended strategy for calling getter methods that have no side effects is to leave the parentheses off when calling the method. As stated in the Scala Style Guide:

“Methods which act as accessors of any sort ... should be declared without parentheses, except if they have side effects.”

According to the style guide, because a simple accessor method like crustSize does not have side effects, it should not be called with parentheses, and this recipe demonstrates how to enforce this convention.

Although this recipe shows how to force callers to leave parentheses off methods when calling simple getters, there is no way to force them to use parentheses for side-effecting methods. This is only a convention, albeit a convention that I like and use these days. Although it’s usually obvious that a method named printStuff is probably going to print some output, a little warning light goes off in my head when I see it called as printStuff() instead.

Side Effects

It’s said that a purely functional program has no side effects. So what is a side effect?

According to Wikipedia, a function is said to have a side effect “if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world.”

Side effects include things like:

Writing or printing output.
Reading input.
Mutating the state of a variable that was given as input, changing data in a data structure, or modifying the value of a field in an object.
Throwing an exception, or stopping the application when an error occurs.
Calling other functions that have side effects.

In theory, pure functions are much easier to test. Imagine writing an addition function, such as +. Given the two numbers 1 and 2, the result will always be 3. A pure function like this is a simple matter of (a) immutable data coming in, and (b) a result coming out; nothing else happens. Because a function like this has no side effects, it’s simple to test. See Recipe 20.1, “Create Methods with No Side Effects (Pure Functions)”, for more details on writing pure functions. Also, see the Wikipedia discussion on side effects in functional programming (FP) applications for more details and examples.