It’s been a while since I’ve written a post on here – and a lot has happened in that time! I’ve started working at another company – a much smaller place with a greater focus on technology and culture, and I’m loving it so far! I’ve learnt a huge deal even in the short time (one month) that I’ve been there, and had many interesting conversations with people.

I do need to start writing again, as I’m worried the huge amount of stuff I’ve learnt will very rapidly fall out of my head, so here’s the first post of a series of random musings based on interesting conversations I’m having or facts I’m picking up along the way. This one’s on a conversation I had this week about immutability.

I’ve started doing a bit of functional programming in Scala and JavaScript, and it’s a very different way of thinking! The key to thinking about functional programming is to realise that in this new world, functions are first class citizens and can be passed around just like variables and other things. But delving into that is another post for another time.

Essentially, functions are designed to be things that takes in a parameter, and spit out the result. They should have no side effects, everything they do is transparent and can be seen by looking at the inputs and outputs. A function “pluralise”, for example, can take in a string and return the same string with an “s” stuck on the end of it:

def pluralise(someString: String): String = {someString + "s"}

There’s no other behaviour attached, it doesn’t go and update a someString field in a class, it literally takes a string, adds an “s” and spits out the new string. What you then do with that string is entirely your business.

If an object is immutable, it is created once and cannot be changed. This is often useful when we want to be assured that the object we are looking at does give us the answer we expect.

In Java, collections are mutable by definition, and you have to explicitly state when you want things to be immutable. In Scala, the opposite is true – collections are immutable by default and if you’d like something to be mutable, you’ve got to state that when creating it.

There are two things to consider when enforcing immutability:

  1. The object itself cannot be changed, e.g. if you had a List, you could not add or remove an item in the list itself
  2. The reference that points to the object cannot be changed, but the underlying object can change

For an object to be completely immutable, both of the above must be true. This means that a reference must always point to the same object, and that object cannot change. To put this into context, the reason this came up was that we were working in Scala and wanted to make a Set mutable. We had to consider which route to go down to do this – should we allow the Set itself to change, or should we create a new Set each time we wanted to add/remove an element and simply point our existing reference to the new Set?

Either option would achieve our goal of a mutable Set, so we had to evaluate which option was better. My initial thought was to simply change the Set itself, as I had thought it pointless to create a new Set and have the garbage collector do extra work when we know that the data is going to change. However I hadn’t considered a key point – that this approach was not thread safe. I.e. if we parallelised work, we could have a thread trying to read from the same Set that another thread was trying to write to. Since this consideration was important to our system, we ended up going for the second approach, of creating a new Set each time a change was made and simply pointing our reference to the new Set.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s