Avoiding Quasi-Immutable Objects in PHP

tl;dr: Immutability in PHP is most practical when the object properties are scalars or nulls. Using streams, objects, or arrays as properties makes it very difficult, sometimes impossible, to preserve immutablity.

One of the tactics in Domain Driven Design is to use Value Objects. A Value Object has no identifier attached to it; only the combination of the values of its properties gives it any identification. If you change any of the properties in any way, the modification must return an entirely new instance of the Value Object.

This kind of behavior means the Value Object is “immutable.” That is, the particular instance is not allowed to change, though you can get back a new instance with modified values. The code for an immutable object looks something like this:

class ImmutableFoo
    protected $bar;

    public function __construct($bar)
        $this->bar = $bar;

    public function getBar()
        return $this->bar;

    public function withBar($newBar)
        $clone = clone $this;
        $clone->bar = $newBar;
        return $clone;

(Note how $bar is accessible only through a method, not as a public property.)

When you create an ImmutableFoo instance, you cannot change the value of $bar after instantiation. Instead, you can only get back a new instance with the new value of $bar by calling withBar():

$foo = new ImmutableFoo('a');
$newFoo = $foo->withBar('b');

echo $foo->getBar(); // 'a'
echo $newFoo->getBar(); // 'b'
var_dump($foo === $newFoo); // (bool) false

With this approach, you are guaranteed that one place in the code cannot change the $foo object at a distance from any other place in the code. Anything that ever gets that instance of $foo knows that its properties will always be the same no matter what.

The immutability approach can be powerful in Domain Driven Design and elsewhere. It works very easily in PHP with scalar values and nulls. That’s because PHP returns those by copy, not by reference.

However, enforcing immutability in PHP is difficult when the immutable object properties are non-scalar (i.e., when they are streams, objects, or arrays). With non-scalars, your object might seem immutable at first, but mutablity reveals itself later. These objects will be “quasi-“, not truly, immutable.

Streams as Immutable Properties

If a stream or similar resource has been opened in a writable (or appendable) mode, and is used as an immutable property, it should be obvious that object immutability is not preserved. For example:

file_put_contents('/tmp/bar.txt', 'baz');

$foo = new ImmutableFoo(fopen('/tmp/bar.txt', 'w+'));
$bar = $foo->getBar();
fpassthru($bar); // 'baz'

fwrite($bar, 'dib');

fpassthru($foo->getBar()); // 'dib'

As you can see, the effective property value has changed, meaning immutability has been compromised.

One way around this might be to make sure that immutable objects themselves check that stream resources are always-and-only in read-only mode. However, even that is not a certain solution, because the resource pointer might be moved by reading operations in different parts of the application code. In turn, that means reading from the stream may yield different results at different times, making the value appear mutable.

As such, it appears that only “read-only” streams can be used as immutable properties, and then only if the immutable object restores the stream, its pointers, and all of its meta-data to their initial state every time the stream is accessed.

Objects as Immutable Properties

Because PHP returns objects as references, rather than as copies, using an object as a property value compromises the immutability of the parent object. For example:

$foo = new ImmutableFoo((object) ['baz' => 'dib']);
$bar = $foo->getBar();
echo $bar->baz; // 'dib'

$bar->baz = 'zim';
echo $foo->getBar()->baz; // 'zim'

As you can see, the value of $bar has changed in the $foo instance. Any other code using $foo will see those changes as well. This means immutability has not been preserved.

One way around this is to make sure that all objects used as immutable properties are themselves immutable.

Another way around this is to make sure that getter methods clone any object properties they return. However, it will have to be a recursively deep clone, covering all of the cloned object’s properties (and all of their properties, etc.). That’s to make sure that all object properties down the line are also cloned; otherwise, immutability is again compromised at some point.

Arrays as Immutable Properties

Unlike objects, PHP returns arrays as copies by default. However, if an immutable object property is an array, mutable objects in that array compromise the parent object’s immutability. For example:

$foo = new ImmutableFoo([
    0 => (object) ['baz' => 'dib'],

$bar = $foo->getBar();
echo $bar[0]->baz;

$bar[0]->baz = 'zim';
echo $foo->getBar()[0]->baz; // 'zim'

Because the array holds an object, and because PHP returns objects by reference, the contents of the array have now changed. That means $foo has effectively changed as well. Again, immutability has not been preserved.

Likewise, if the array holds a reference to a stream resource, we see the problems described about streams above.

The only way around this is for the immutable object to recursively scan through array properties to make sure that they contain only immutable values. This is probably not practical in most situations, which means that arrays are probably not suitable as immutable values.

Settable Undefined Public Properties

Finally, PHP allows you to set values on undefined properties, as if they were public. This means it is possible to add mutable properties to an immutable object:

$foo = new ImmutableFoo('bar');

// there is no $zim property, so PHP
// creates it as if it were public

$foo->zim = 'gir';
echo $foo->zim; // 'gir'

$foo->zim = 'irk';
echo $foo->zim; // 'irk'

Immutability of the object is once again compromised. The only way around this is to impelement __set() to prevent setting of undefined properties.

Further, it might be wise to implement __unset() to warn that properties cannot be unset.


If you want to build a truly immutable object in PHP, it appears the best approach is the following:

  • Default to using only scalars and nulls as properties.
  • Avoid streams as properties; if a property must be a stream, make sure that it is read-only, and that its state is restored each time it is used.
  • Avoid objects as properties; if a property must be an object, make sure that object is itself immutable.
  • Especially avoid arrays as properties; use only with extreme caution and care.
  • Implement __set() to disallow setting of undefined properties.
  • Possibly implement __unset() to warn that the object is immutable.

Overall, it seems like immutability is easiest with only scalars and nulls. Anything else, and you have a lot more opportunity for error.

Remember, though, there’s nothing wrong with fully- or partially-mutable objects, as long as they are advertised as such. What you want to avoid are quasi-immutable objects: ones that advertise, but do not deliver, true immutability.

(For some further reading, check out At What Point Do Immutable Classes Become A Burden?)


Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.
Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

15 thoughts on “Avoiding Quasi-Immutable Objects in PHP

    • Yes, and I think it’s important to distinguish between value objects and immutable objects in general. Value objects certainly should not have mutable objects as properties, but an object representing the content of a file is not a value object and still can be considered immutable.

  1. “When you create an ImmutableFoo instance, you cannot change the value of $bar after instantiation”

    Well … hmmm …

      • Well now, that’s pretty tricky. I’ve never tried calling a constructor after instantiation. Does that mean, for a “truly” immutable object in PHP, you can’t even have a public constructor? (Or at least you need to have guard clauses in the constructor to prevent a second invocation.)

        • Or use a named constructor and set the __construct private? like

          private function __construct() {}
          public static function write($title, $content) {
          $post = new Post;
          $post->title = $title;
          $post->content = $title;

          return $post;

          This way we can preserve immutability?

  2. thanks for the article,

    it looks like you have a typo in your code example

    $foo->zim = ‘gir’;
    echo $foo->zim; // ‘dib’

    there should be ‘gir’ in the second line, not ‘dib’

  3. What about ‘write-only’ streams? e.g.

    $stream = fopen(‘/black/hole/for/output’, ‘a’);
    $app = new Application($stream);

    seems like a reasonable paradigm.

    • Now that’s a funny thought! I suppose it depends on if we think of “immutable” as “you cannot *see* any changes through the object” vs “you cannot *effect* any changes through the object.”

      • I’m drawn towards Yegor’s distillations of David West’s object thinking:

        I.e. an object encapsulates a unique real world object, and the mutability of the file, http resource etc. doesn’t affect immutability of the object itself. As he puts it “immutability means loyalty”.

        In that case immutability determines that a stream always refers to the same “thing”, and (if I’m not abusing the term) side effects are determined by the manner in which an application interacts with the stream.

        • I’ve heard that argument elsewhere, and while I see what he’s saying, I disagree.

          In particular: “The encapsulated data is the coordinates of the entity being represented.” As the user of the immutable object, at least in PHP, I don’t especially care that the property always refers to the same internal memory pointer, and cannot be changed to point at something else. (Forgive the strictly technical misuse of “pointer” here; I hope you get what I mean.)

          Further, Yegor says, “I’m suggesting to re-think a traditional interpretation of “immutability” in OOP. I understand that it may sound controversial, but I believe that it makes sense. At least for me” (http://disq.us/p/y81m02)

          If immutability is loyalty, then I want the immutable object to be loyal to my expectations as the user. That expectation is that the apparent contents of the object do not change “at a distance.”

Leave a Reply

Your email address will not be published. Required fields are marked *