Question

Calling expert Scala developers! Let’s say you have a large object representing a writable data store. Are you comfortable with this common Java-like approach:

val complexModel = new ComplexModel()
complexModel.modify()
complexModel.access(...)

Or do you prefer:

val newComplexModel = complexModel.withADifference
newComplexModel.access(...)

If you prefer that, and you have a client accessing the model, how is the client going
to know to point to newComplexModel rather than complexModel? From the user’s perspective
you have a mutable data store. How do you reconcile that perspective with Scala’s emphasis
on immutability?

How about this:

var complexModel = new ComplexModel()
complexModel = complexModel.withADifference
complexModel.access(...)

This seems a bit like the first approach, except that it seems the code inside withADifference is going to have to do more work than the code inside modify(), because it has to create a whole new complex data object rather than modifying the existing one. (Do you run into this problem of having to do more work in trying to preserve
immutability?) Also, you now have a var with a large scope.

How would you decide on the best strategy? Are there exceptions to the strategy you would choose?

Answer 1

I think the functional way is to actually have Stream containing all your different versions of your datastructure and the consumer just trying to pull the next element from that stream.

But I think in Scala it is an absolutely valid approach to a mutable reference in one central place and change that, while your whole datastructure stays immutable.

When the datastructure becomes more complex you might be interested in this question: Cleaner way to update nested structures which asks (and gets answered) how to actually create new change versions of an immutable data structure that is not trivial.