Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 548 posts at DZone. You can read more from them at their website. View Full User Profile

Scala: val, lazy val and def

  • submit to reddit

We have a variety of val, lazy val and def definitions across our code base but have been led to believe that idiomatic Scala would have us using lazy val as frequently as possible.

As far as I understand so far this is what the different things do:

  • val evaluates as soon as you initialise the object and stores the result.
  • lazy val evaluates the first time that it’s accessed and stores the result.
  • def executes the piece of code every time – pretty much like a Java method would.

In Java, C# or Ruby I would definitely favour the 3rd option because it reduces the amount of state that an object has to hold.

I’m not sure that having that state matters so much in Scala because all the default data structures we use are immutable so you can’t do any harm by having access to them.

I recently read an interesting quote from Rich Hickey which seems applicable here:

To the extent the data is immutable, there is little harm that can come of providing access, other than that someone could come to depend upon something that might change. Well, okay, people do that all the time in real life, and when things change, they adapt.

If the data was mutable then it would be possible to change it from any other place in the class which would make it difficult to reason about the object because the data might be in an unexpected state.

If we define something as a val in Scala then it’s not even possible to change the reference to that value so it doesn’t seem problematic.

Perhaps I just require a bit of a mind shift to not worry so much about state if it’s immutable.

It’s only been a few weeks so I’d be interested to hear the opinions of more seasoned Scala users.

I’ve read that there are various performance gains to be had from making use of lazy val or def depending on the usage of the properties but that would seem to be a premature optimisation so we haven’t been considering it so far.



Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Sirikant Noori replied on Sun, 2012/01/15 - 12:39pm

Making a val lazy entails a code-size and runtime overhead.  Idiomatic Scala would be to use lazy only when you need them.  Mostly this is:
a) When initialising the object is computationally expensive and may not need to happen
b) When mixing traits into a class and you don't want instance variables getting used before everything has initialised.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.