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.

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.
Ken