The mutant

Peter Bayne
Jun 28, 2016 · 3 min read

This is part 2 of a series of handling change within immutability. Today we are going to “cheat” by going against all of our best functional language intentions and actually create a mutable object.

Why would you intentionally create a mutable object in a language founded on mutability?

Well, let me tell you a story… I was working with a team that used the .Net stack, and C# by default, with a fairly complex inter-related class structure. When .Net 3.5 came around some of us were excited by the lambda functions and linq sub-language, and without knowing it the architecture started looking pretty functional. Once we recognised this, it was an obvious next step to look at F# for some of the logic work. So we ended up with a hybrid application that was partially OO and partially functional, which actually worked pretty well for us.

However, when it came to users maintaining the data structures the infrastructure was designed to work with mutable, persisted classes. Inevitably, the F# data structures needed to follow suit.

Thankfully, as F# is still part of the .Net family, it can be made to play by these rules too. The language supports properties with setters as well as getters, and highlights the fact that we are mutating an object with a specific syntax; the “<-” symbol.

This symbol is especially reserved for changing the value of an existing value, and the value has to be specifically declared as mutable. To create a simple mutable value, you can just add the mutable keyword in the declaration (along with an initial value).

Mutable Classes with Properties

After a bit of research we found the F# for fun and profit page on classes. Now we can create a mutable, complex class with automatic properties, like so:

Also, in the more complex case where you want to use an explicit mutable backing field…

* Note the use of the <- symbol in the setter.

This allowed us to create a mutable class that could be updated by the existing UI layer and passed to the existing persistence layer for saving to the db.

As you can see, the code is starting to look a little un-functional and really more like C# code with an F# syntax. This seemed to be an almost inevitable by-product of interfacing with an OO language so closely, at least along the interfaces. However, It did allow us to move incrementally into a better (not biased at all !) language, and as the code moved away from the interface it became more functional and took better advantage of the language.

Ultimate this is my least favourite way of dealing with change, but it can serve a useful purpose.

Continuing on

This is article #2 in this series. Next time, we’ll be looking at a purely functional solution that allows us to more easily update data within a structure; Lenses.

  1. Records: Just like the that one, only different.
  2. The OO way: implementing property setters in F# to “cheat” by creating a C#-style mutable object.
  3. Lenses: changing the thing inside the thing inside the other thing
  4. Lenses and lists: changing the thing amongst the other things in that thing…maybe
  5. Two-way Type Providers: reflecting changing external data
  6. Some common things that usually rely on mutation: like sorting…
Peter Bayne

Written by

Principal Consulting Software Developer at Haumohio.com, based in beautiful Christchurch, NZ. Writing about devops, F#, and software dev in general.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade