Blog

A while back, I announced the release of my AttributeUtils library and its powerful attribute-based analyzer.

That library was built primarily to support the many edge cases I needed for Crell/Serde, a new, robust serialization/deserialization library built specifically for PHP 8.1.

Enumerations are a feature of many programming languages. However, we should perhaps say "many languages have a feature called enumerations." What that means in practice has a lot of language-specific semantic nuances, and trying to use the feature of one language as though it were the feature of another language can lead to all kinds of broken code. (That's true of most language features.)

So how are Enumerations best used in PHP, specifically? Let's have a look at some examples and see where they should, and shouldn't, be used.

I was discussing recently with a TYPO3 colleague about performance, specifically caching. Both he and I are working on systems that may involve hundreds or thousands of objects that need to be cached for later use. The objects themselves are fairly small, but there's a large number of them. The data format is only internal, so we don't need anything standardized or parsable by outside systems.

PHP actually has two options for this use case: serialize()/unserialize() and var_export()/require(). But which is better?

Quick, to the benchmark mobile! The results I found were not at all what I expected.

null is controversial, and often derided. But let's go a bit deeper and understand what it means to mean nothing, and let that guide us to better error handling.

Announcing AttributeUtils

After sitting on it for a while, I am pleased to release a PHP library for robust, powerful attribute handling in PHP 8.1: Crell/AttributeUtils. It's a robust, centralized tool for slicing, dicing, and reverse engineering classes in PHP using attributes.

Last time, I talked about fun uses of the match() expression in PHP, using unconventional types of expressions on the right-arm branch. This time, I want to expand that discussion to include fun tricks on the left-side of the =>, and how you can easily match by multiple values at the same time.

I'm going to assume you have read the previous installment about how match() works and what an "expression" means. Also, I don't claim to be the original source of these tricks. I'm just documenting them because they're cool. Let's dive in.

Recently, I've been helping a new developer out in a chat room. He's still learning PHP and working through tutorials, with lots of questions along the way. Earlier this week, by accident, he stumbled across a use of match() statements I'd not considered before. While technically not right for his use case, it did suggest another, potentially valid use for match() I'd not seen. Let's add it to the list of cool things you can do with match().

This is old-hat to some people, but it's still a nice trick.

PHP has long supported Java-esque property and method access control. Object properties and methods may be marked public, protected, or private to control what other code may access them. The general recommendation for years is that properties should be non-public in almost all cases, unless you're using the new readonly flag in PHP 8.1.

(There's a good case to be made that object-level encapsulation is the wrong model in the first place, and package-level visibility is the superior model. I happen to agree with that argument, but that's neither here nor there for the time being.)

Most of the time, you want to respect the visibility set by the code's author. It's telling you how an object should be used, and if you do otherwise you're on your own. However, there are cases in meta-programming situations where you need to be able to bypass the visibility in order to manipulate the state of an object in a dynamic fashion. The most common scenarios are serialization, de-serialization, hydration from an ORM, and similar.

Over the last few weeks, I've been following Advent of Code 2021, using Functional PHP as an approach. It's been a fun and educational process, at least for me and apparently for a few other people, at least given how popular the articles have been.

For reference, the full list of articles in this series is here:

• Day 1: Function composition, pipes, and partial application.
• Day 2: Map, reduce, generators, immutable objects, and with-er methods.
• Day 3: Recursion, memoization, and bits.
• Day 4: First, head, array flattening, and handling state.
• Day 5: Zip and nested pipes.
• Day 6: Efficiency and dealing with infinite streams.
• Day 7: Functional means and medians
• Day 8: Encoding, decoding, and the value of first-class function thinking.
• Day 9: More fun with recursion.
• Day 10: Reduction and recursion, and how to swap between them.

After letting those sit for a few days, I want to use those examples as a way to evaluate how well PHP handles functional-style programming and what improvements we could make to the language to make it even better.

For the 10th Day of Advent of Code, we're asked to solve a matching braces problem. This is a common parser exercise, but it's made a bit more complex in this case by using multiple types of braces. Specifically, we're handling a series of lines that contain ( and ), but also < and >, [ and ], and { and }.

The story jazzes it up as being the code of our submarine's navigational computer, which consists entirely of braces in a sort of eldritch horror version of brainfuck, but that's mostly just a distraction.

We're told up front that most of the data lines are bad. None, in fact, are properly balanced. Some are corrupted by having an invalid character (say, a ] closing when a } closing was expected), while others are just incomplete. (Seriously, who wrote this submarine's computer system?)

The instructions say to ignore incomplete lines for part one and consider only corrupted lines. It's a safe bet that part two is going to have us consider the incomplete lines (spoiler alert: it does), so let's save time and consider both possibilities. The problem, then, is to find lines that are corrupted and find their first illegal character.

Then we want to turn the character into a point count and add those up, again mostly just to prove that we did it with a single final answer. Let's have a go at it.