Designing with immutability (in Scala)

Question

With the emphasis on immutability in programming language like Scala (avoid "var"), does it mean "state-modifying methods" in my object will have to return a copy of the instance (with the new state)?

Let's consider turtle. I would like to move my turtle like this:

val turtle = new Turtle(0, 0, "north") val turtle2 = turtle.turnLeft().forward(5).turnRight().backward(2)

Here turtle2 wouldn't point to the same instance of Turtle (they're two separate instances). In fact, in that sequence of movements 4 interim objects were created. This is how I would implement the method turnLeft, for example:

def turnLeft { self.copy(orientation = self.orientation match { case "north" => "west" case "east" => "north" case "south" => "east" case "west" => "south" }) }

Is that a correct design approach?

If yes, how efficient / inefficient is that (creation of new object on every method call)? If no, what would be the right one? What is wrong / missing in my understanding of immutability aspect (or maybe functional programming in general)?

Thanks in advance, Raka

I think your code looks correct (from an immutable POV). In terms of efficiency I think it will certainly not as fast as a single mutable pre allocated object. The overall impact will depend on how fast and frequently you want to move the turtle. — Soumya Simanta
– Soumya Simanta, Commented Jan 4, 2015 at 2:14

Dima · Accepted Answer · 2015-01-04 03:32:30Z

Creation of lots and lots of short-lived objects is a hallmark feature of scala. It is generally not very expensive, provided you run it on a JVM with adequately sized heap, having a sufficient amount of young generation memory to accommodate all of the churn.

Having said that, immutability is not a religion. Common sense should prevail, and guide the design decisions where sticking to the "paradigm" becomes too taxing.

Thanks for the response. I don't mind then with this approah (of creating short-lived objects). ... It's just... having to manually do "self.copy(...)" on my "state-modifying" methods looks cumbersome. Is there a better way to do that in scala (special annotation for the method maybe)?
well, copy(foo=bar) hardly seems too much more "cumersome" than foo=bar; return this, does it? Or am I missing something?

David Frank · Accepted Answer · 2015-01-06 23:41:14Z

I think, it's important to consider whether or not you want to handle your Turtle as an entity.

If I have a car and I turn the wheel right, the car goes right (in optimal case :P), then I turn the wheel left, and it goes left, but it's still the same car. The same is true for a turtle. Although immutability usually makes programs more easily understandable, there are cases when it's less intuitive.

Think about whether a right heading and left heading turtle are different. Of course, equality checking can be overriden, so it's rather a theoretical difference whether the old and new turtle (with the same name/id) are the same by only equality or also referentially.

Collectives™ on Stack Overflow

Designing with immutability (in Scala)

2 Answers 2

2 Comments

Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

2 Comments

Comments

Related