如何在保留不变性的同时访问Scala中的复杂数据结构？

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.

Answer 2

The canonical answer to your question is using Zipper , one SO question about it .

The only implementation for Scala I know of is in ScalaZ .

Answer 3

By such name of method as modify only it's easy to identify your ComplexModel as a mutator object, which means that it changes some state. That only implies that this kind of object has nothing to do with functional programming and trying to make it immutable just because someone with questionable knowledge told you that everything in Scala should be immutable will simply be a mistake.

Now you could modify your api so that this ComplexModel operated on immutable data, and I btw think you should, but you definitely must not try to convert this ComplexModel into immutable itself.

Answer 4

Immutability is merely a useful tool, not dogma. Situations will arise where the cost and inconvenience of immutability outweigh its usefulness.

The size of a ComplexModel may make it so that creating a modified copy is sufficiently expensive in terms of memory and/or CPU that a mutable model is more practical.