In a new post Larry Garfield suggests and interesting approach to arrays in PHP: stop using associative arrays (or at least "basically never").

The other day I was working on some sample code to test out an idea that involved an object with an internal nested array. This is a pretty common pattern in PHP: You have some simple one-off internal data structure so you make an informal struct using PHP associative arrays. Maybe you document it in a docblock, or maybe you're a lazy jerk and you don't. (Fight me!) But really, who bothers with defining a class for something that simple?

But that got me wondering, is that common pattern really, you know, good? Are objects actually more expensive or harder to work with than arrays? Or, more to the point, is that true today on PHP 7 given all the optimizations that have happened over the years compared with the bad old days of PHP 4?

So like any good scientist I decided to test it: What I found will shock you!

He starts by describing his test environment (a local environment, not a cloud one) and the code for his baseline tests. The code generates an array of one million items where each item is an associative array of an integer/string combo. He wants to see what kind of memory consumption is involved in the creation and processing of this data set via sorting. His second test evaluated the serialization size (again, code provided) again checking the memory consumption. He shares the results of these tests and then moves on to similar tests on:

• stdClass instances
• objects with public properties
• objects with private properties
• anonymous classes

The post ends with a summary showing the results of all tests side-by-side with some interesting results (but you'll have to check out the post for yourself if you want to see those).

On the QaFoo.com blog they've made a recommendation in their latest post - they suggest that you never use null.

When doing code reviews together with our customers we see a pattern regularly which I consider problematic in multiple regards – the usage of null as a valid property or return value. We can do better than this.

Let's go into common use cases first and then discuss how we can improve the code to make it more resilient against errors and make it simpler to use. Most issues highlighted are especially problematic when others are using your source code. As long as you are the only user (which hopefully is not the case) those patterns might be fine.

They talk about some of the most common uses they see for using null in PHP applications including setters for class properties (injection). They point out that in PHP 7 a missing value on a property would result in a Fatal error and make the functionality harder to test overall. They suggest that all required dependencies be injected on object construction instead, making it easier to know the current state of the object on testing. They also talk some about using null as a return value, how it could make debugging difficult and a solution that could make more sense - throwing an exception instead.