On the Stovepipe Systems blog today Yannick de Lange has written up a post looking at data immutability and how using this concept can help improve your development and simplify data handling in your applications.

When dealing with enterprise software, your data is often the most valuable part. It contains all your customer information, contracts, invoices and much more. So what are you going to do to make sure the data is being dealt with correctly? A bug in your code can have a high impact on the integrity of your data. If the bug is causing unwanted changes in your data, fixing the damage might prove to be quite a big challenge.

With this post I would like to show how data immutability can help design a more robust system. One that is less susceptible to bugs that might make unwanted changes to your data.

He starts by talking about how immutability and data handling might seem like "a contradiction" but that it can, instead, be thought of as "versioning your data". He gives an example of an end date on a contract and how changing it directly leads to data loss. He then gets into an actual code example showing how to implement this data versioning. He starts by creating the basic "Contract" object but then refactors it into "versioned" types and how the changes would be tracked internally, updating with each change to the data instead of overwriting.

Simon Holywell has continued his series looking at immutability and PHP in part two of his series improving on the code and classes from the previous post.

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.

He then moves on from the "simple" mutation method previously used (making a new immutable object when a property changes). When the property list starts getting more complex simple single value references no longer scale. He makes use of methods internal to the class to modify the values and return a new immutable instance with the updated value. He shows how to modify this to prevent the setting of unexpected properties and how to expand it out to allow the input of an array of values to update and how to handle required/optional property values.

Andrew Carter has written up a new post about PSR-7 objects (the PHP-FIG defined standard for handling requests and responses in PHP applications) and how the objects themselves are immutable.

What’s happening [in the provided example] is that the Zend Expressive framework is rendering the error page to the same object that you wrote your message to. Whilst the actual message object itself is immutable, the body stream that it references is not. Even when this object is cloned or “modified” (to become a new object) it will still use the same stream.

He explains a bit about what this means in a more practical sense and why the PSR-7 standard and why this happens (as defined after much discussion). Then he gets into a more recent debate happening in the PHP-FIG about PSR-7 middleware and the proposal for a standard structure in its creation. He points to some of the thoughts from Anthony Ferrara on the topic and an example from Woody Gilk showing an exception handler and how having the stream always appending content is a bad thing in that particular case.

The PHP Roundtable podcast has posted their latest episode, recorded live with host Sammy Kaye Powers and guests Larry Garfield, Matthew Weier O'Phinney and Glen Hickle talking about immutability in PHP.

Immutability plays a huge role in functional programming and many languages support immutability directly; like the readonly keyword in C#. It is possible to create immutable objects in PHP, but the language lacks inherent immutable features for scalar variables and class properties. We discuss how to bring functional programming concepts to PHP and brainstorm some features that could possibly be added to future versions of PHP to offer better immutability support.

You can watch the live recording of this latest episode either through the in-page video player or directly over on YouTube. If you enjoy the show, be sure to also subscribe to their feed and follow them on Twitter for information on the latest episodes (and when future live recordings are happening).

In a new post to his site Dave Hulbert has shared some of his thoughts about the PSR-7 standard, a HTTP proposal for HTTP handling.

PSR-7 contains interfaces for HTTP messages. These are like Symfony Kernel's Request and Response interfaces. Having these new interfaces would be great for the PHP community but there's a couple of issues with their current state that I'm not happy with.

One of PSR-7's goals is "Keep the interfaces as minimal as possible". I think the current interfaces are not minimal enough.

He breaks down his thoughts into a few different sections covering ideas around:

• Immutability and PSR-7's enforcement of mutability
• Being too strict to the (HTTP) spec
• Splitting client and server message interfaces
• Writing and reading from StreamableInterface

He sums up his thoughts under each section pretty quickly. If you haven't heard much about the PSR-7 proposal and want more context on what he's referencing, check out this proposal (or other posts sharing opinions from other developers).