2

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?

James McCabe
  • 1,879
  • 2
  • 15
  • 22

4 Answers4

3

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.

Community
  • 1
  • 1
Jens Schauder
  • 77,657
  • 34
  • 181
  • 348
  • That is true. Here is some more info. The mutable context should use STM... Look Agent in Akka. Updating structure should use lenses and states to stay functional, look at Scalaz. This kind of Stream is often called Event Sourcing. – Andy Petrella Jul 08 '12 at 21:21
  • Are there any open-source projects I can browse as examples of this strategy of "have Stream containing all your different versions of your datastructure and the consumer just trying to pull the next element from that stream" ? – James McCabe Jul 17 '12 at 11:39
1

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.

Community
  • 1
  • 1
pedrofurla
  • 12,763
  • 1
  • 38
  • 49
1

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.

Nikita Volkov
  • 42,792
  • 11
  • 94
  • 169
0

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.

Donald.McLean
  • 869
  • 12
  • 18
  • Yes but some people are going to complain that you're not getting the main advantage of Scala if your data structures are not immutable, and that you might as well still be in Java. – James McCabe Jul 08 '12 at 21:11
  • Functional programming is hardly the only advantage Scala has over Java. For a really complex model, I would be tempted to wrap it in an actor - which is not, generally, a Java solution for anything. – Donald.McLean Jul 08 '12 at 23:32