In the last article we learnt how to create an immutable data structure in PHP. There were a few issues to work through, but we got there in the end. Now onto making the immutable class more useful and easier to create modified copies. Note that these are copies and not modifications, in-place, to the original objects.

This article is part of a series I have written on the topic of immutability in PHP code:

  1. Part one - a discussion of caveats and a simple scalar handling immutable
  2. Part two - improve the process of creating modified copies of the immutable
  3. Part three - objects in immutable data structures and a generalised immutable implementation

Simple parameter mutations

When you want to modify a property in an immutable object you must, by definition, create a new object and insert the modified value into that new location. You could simply get the values from the current instance and pass them into a new instance as you create it.

So simple. Too simple!

This technique works reasonably well for this small dataset, but what if we had five or ten parameters that would have to be replayed every time? An exaggerated example to illustrate my point follows.

It is certainly doable, but I, for one, am not going to be executing that every time I need to work with an immutable instance. Certainly, not if I can avoid it.

Mutation at clone time

There is a very handy quirk in PHP that we can exploit. It will allow us to create new modified copies of the object in question.

Instead of mutating the object in place like you would in traditional OOP, we’re going to make a clone of the object and changes it’s private properties. Yes, you read that correctly, you can change the private properties of a class instance!

So you’ve probably learnt that private means that a class property cannot be changed from outside or by other classes overriding it. Whilst this is generally true; when we clone an object we get a fleeting opportunity to change it’s private properties.

Well that didn’t work! I should’ve said that you can only perform the clone from within a method of the same class to be able to modify it like this.

In this way it becomes easier to modify a value inside an immutable - we can wrap up the clone and set the right values for them. Having a shortened syntax like this really serves to help implementers work with immutable objects.

Preventing the setting of unexpected properties

There are other ways that a seemingly immutable class can be messed with too. Fortunately, these can be stopped with a couple of PHP magic methods.

In PHP it is possible to add properties to a class at run time - even a final class. We don’t want this as it would change the shape of our class and therefore mean that it was mutable. The simple way to prevent this is to add an empty __set() magic method implementation to your class.

It is also possible to remove property values by using the unset() construct. We can also prevent this using another empty magic method:

It is important to ban these. Whilst they do not allow modification of our private properties - they do allow outside agents to change our immutable class by adding and remove their own public properties. The class would no longer be immutable were this allowed to happen.

Merged clone time mutation

So far we’ve seen the ability to change one property using a withX style method, but what if we want to change more? Well, you could just chain the changes up with something like this.

Whilst it works, there are a few things that I dislike about this approach. A throwaway instance is created between the calls to withX() and withY(), you have to create a with*() function for every property and the method chaining quickly gets irritating.

There is, of course, another way.

First, let’s define a new immutable class with a few properties.

To keep the example shorter, I’ve employed a small __get() magic method instead of writing a get method of each property the class. You would have to write one for each ending up with functions like getEngineCc(), getBrakes() and getTractionControl(). Instead you access them directly as properties instead.

Anyway back to the mutations! To allow for the easy manipulation of the classes properties when cloning we can add a simple method to the class.

Now when you want a new class with modifications - perhaps when you’re releasing a new motorbike model - you can just call with() and include an associative array.

While it works OK, you may have noticed that we’ve now effectively eliminated the ability for PHP to type check the input. We’re no longer populating the class via the constructor.

This is bad because a non-scalar value could be passed in (more on why this sucks in a future article).

One way we could solve this is to replace with() with a function that uses reflection to workout the constructors parameter order and merge newly supplied values in.

When the new class instance is created the newly supplied values are passed to the constructor, which ensures that they’re correctly type checked.

You would call this method in the same way as the last with() implementation. It does make the assumption that the class properties will have the same name as the constructor parameter name ($this->engineCc is the same as constructor parameter $engineCc for example).

This would leave you a final Bike class of:

Also bear in mind that the reflection API provided by PHP is not crazily quick so if micro-optimisations are your thing then you’d probably want to avoid this. If you can take the hit then the extra security you get from the type checking is worth it.

Using a builder to generate immutable objects

Another way around this particular issue with immutable objects can be to use a second class to generate the immutable objects. This will allow you to avoid the use of the Reflection API and still give you the advantage of type checking. A little touch of irony here as we’ll use a mutable builder class to produce an immutable object, but bear with me.

Firstly, we need to define the immutable object our builder will produce. I am removing the __get() magic here too as our aim is to make it easier for our code to be analysed statically. This will help IDEs to type hint, code quality tools to read our code and ostensibly make the code easier to follow cognitively.

Now we have a simple little immutable class we can get on with the business of creating a generating class. This new class will accept all the values we wish to store in the immutable class and return an instance of Bike.

The BikeGenerator duplicates some code of the original class and really serves as a glorified queue. We add to the queue until we’re happy and execute build() to be given a freshly populated instance of Bike.

This shows a use of the builder pattern to generate a ready made immutable Bike instance. You can then call ::with() to easily create a new modified version of an existing object.

Setting larger amounts of properties

There is not all that much that you can do remove the tedium of dealing with many values in an immutable with PHP. One way to get past this is to pass in an array of values that are checked and stored in the immutable.

We’ve had to eschew the type system in favour a small custom type check defined in the $properties class property and evaluated in the setValue() method.

The way that this works also makes it easy to handle optional arguments at instantiation - up until this point all arguments have been mandatory. Here you can supply an array missing one or more properties and they simply won’t be set in the $this->data array.

There are further improvements that could be made here to make the class better able to handle non-existent values, but they’ll have to be the subject of another article.

Also, note that the way the set() method is designed means that it will silently ignore properties passed to it that do not exist in the $properties class property. You may wish to change this to throw an exception or warning depending on your use case, of course.

Merging larger collections of properties

It is a very simple exercise to perform a merge now that we have an array for the value store and we’re accepting an associative array for input. We can add the following method to the Config class.

This can then be exercised with:

By writing the code this way, we’ve effectively written our own little implementation of named parameters too. As great as that may be we’re also losing some clarity and IDE type hinting with the inherent indirection.

Anyway you cut it, manipulating an immutable in PHP can get annoying pretty quickly. There appears to be no really simple way of avoiding typing more and/or affecting the type hinting abilities of IDEs. These are some of the techniques I’ve used before to workaround some of the frustration, but there is definitely room for improvement.

This article is part of a series I have written on the topic of immutability in PHP code:

  1. Part one - a discussion of caveats and a simple scalar handling immutable
  2. Part two - improve the process of creating modified copies of the immutable
  3. Part three - objects in immutable data structures and a generalised immutable implementation

If you like this article then you might get a kick out of writing functional php code as taught in the Functional Programming in PHP book that I wrote.