Never* Use Arrays

By Larry Garfield

Arrays are a core feature of the PHP language, and so easy to use many developers don’t go beyond them. Fixating on arrays as the uber-data structure, while tempting, can rapidly lead to unmaintainable, unreadable code. Let’s look at better options and just how accessible those options are.

Read in Full

This article was originally published in the January 2020 issue of php[architect] magazine. To read the complete article please subscribe or purchase the complete issue.

Responses and Pingbacks

still-dreaming-1 on
May 12th, 2020 at 4:47 pm

A better way to achieve type safety is to use Psalm. Then you can have generic like typing (but with more flexibility that most languages with generics) and types are checked at static analysis time (sort of like “compile” time) instead of runtime. You can use this with either an actual array, or an ArrayObject, or just about anything you want.

Using or extending ArrayObject can be useful when you really want the performance characteristics of php arrays (hash tables), but you want it to be passed around as an object instead of copied every time like arrays. This combined with Psalm and the techniques in the article can be useful.

But most of the time, you don’t really want the performance characteristics of arrays, since they are actually just hash tables. Because of the performance characteristics of hash tables, they are supposed to be used only when very explicitly chosen by the programmer. The fact that PHP uses them by default is completely ludicrous. Using ArrayObject or your own wrapper classes around an array doesn’t help with this. You are better off using the ds/data structures extension for php, and then inheriting from those classes or making wrapper classes around them if needed, but you may not need to. These data structures are not written in PHP and so they are not just hash tables under the hood. They are designed to have the performance trade-offs these data structures are supposed to have, allowing you to pick the right data structure for the right job. You can also use these classes in combination with Psalm to get generic like static typing (at static analysis time).

I recommend thinking of Psalm as your php compiler in the sense that you should not ship php code that still has Psalm errors, the same way you would not ship Java code that still has compile errors. Or at least you should only ship with explicitly ignored Psalm errors (either ignored in the php code, your Psalm baseline, or your Psalm config).

I still think it would be nice to actually have generics build into the language. In that case, Psalm could still statically check your types, but more of them could be naturally expressed directly in the code instead of in docblocks. But the amazing flexibility and strictness of the Psalm’s static analysis will never get completely replaced by PHPs own types and other features. Psalm is light years ahead of the design of the PHP language. You can think of using PHP with Psalm as already having access to PHP version 30, meaning it is almost as well designed as other languages that actually have a design, like Kotlin.

Leave a comment

Use the form below to leave a comment: