Advent of Functional PHP: Day 3

Submitted by Larry on 4 December 2021 - 6:15pm

The third challenge in this year's Advent of Code is all about bit manipulation. We're asked to read in a series of binary numbers and interpret them in various entirely illogical ways as a form of diagnostics. (Incidentally, if you ever write a system that requires this kind of logic to debug its output, you're fired.)

In any case, we're given a file with a list of 12 digit binary numbers and asked to compute various values. In the first part, we are asked to find the most common bit (0 or 1) in each position, and the result is known as "gamma." Then we have to find the least common bit in each position, and the result is known as "epsilon." (I don't know why you would want to do this; it's all Greek to me.)

Advent of Functional PHP: Day 2

Submitted by Larry on 2 December 2021 - 11:46am

In today's challenge, we're asked to interpret a series of basic command lines from a file and update the position of our submarine accordingly. It's basically a graph walk of sorts, with instructions of up, down, and forward. (Apparently you cannot go backward, as in life.)

As with yesterday's challenge, we could do it imperatively with a foreach() loop and a couple of state variables floating around, but that conflates a whole bunch of different behaviors into one blob of code. We don't want to do that, so let's step back and consider the problem more clearly.

Advent of Functional PHP: Day 1

Submitted by Larry on 1 December 2021 - 11:24am

today's challenge asks us to interpret a list of numbers. In the first part, our goal is to determine how many elements in the list are larger than their immediate predecessor.

The imperative way would be to toss it in a `foreach()` loop and track some state along the way. But we want to be functional and avoid "track some state," because the whole point of functional programming is to avoid tracking state, as tracking state is error prone.

When looking at a foreach-style operation that has some state, my first inclination is to look at a reduce operation. A reduce operation walks over a list and performs the same operation (function) on each item, using the output of the previous iteration as an input. That is, each step takes the output of the previous operation and the next element, and produces an output. It's quite elegant.

Advent of Code 2021: Functional PHP

Submitted by Larry on 29 November 2021 - 6:45pm

I am planning to participate in Advent of Code this year. For those not familiar with it, it's a daily coding challenge that runs through December, until Christmas. Mostly it's just for fun, but some people take it as an opportunity to either push themselves (by solving the puzzles in a language they're unfamiliar with) or to show off some feature of a language they like, which they then blog about.

In my case, I'll be solving puzzles in PHP, of course, but specifically using functional techniques. My goal is to demonstrate how functional programming in PHP is not just viable but creates really nice solutions. At least, I hope it works out that way; I haven't seen any of the challenges yet. :-)

Evolving PHP safely

Submitted by Larry on 27 November 2021 - 12:37pm

This past week, the latest PHP RFC, Deprecate Dynamic Properties, passed 2:1. It just barely met the 2/3 vote threshold for passing, which of course can and has been spun in various pro-and-con ways. The RFC covers the change itself fairly well so I won't go into detail about it here.

The main argument people had against it was that it involves triggering deprecation warnings. Which... is kind of the point. That's kind of all it does.

This is not the first time that debate has come up, but it's been coming up more frequently and we, as PHP, need to improve the answer.

(Continue reading this post on PeakD.)

PHP Tricks: Lazy public readonly properties

Submitted by Larry on 12 November 2021 - 10:50am

I am apparently late in coming to this trick, but PHP 8.1 is going to make it even nicer to use.

A clever trick

There's an interesting intersection of functionality in PHP:

  • Declared object properties are more efficient than dynamic ones, because the engine can make assumptions about what data type to expect.
  • The magic `__get()` and `__set()` methods trigger when there is no property with a given name that has been *set*.
  • Fun fact: A property that has been declared but not initialized with a value is still technically "set"... to `uninitialized`.
  • However, you can `unset()` an uninitialized property.

That means you can do clever tricks like this (and some systems do, internally):

Continue reading this post on PeakD

Fun with PHPUnit Data Providers

Submitted by Larry on 24 August 2021 - 12:13pm

Most PHP developers are familiar with PHPUnit these days. It is the most widely used testing framework for PHP by a wide margin (although others do exist). One of its more under-utilized features, though is data providers.

Data providers are a PHPUnit feature (and many testing frameworks have an equivalent) that lets you run a single test method multiple times but with different data. Often it's presented as a way to save typing, but I find it is also a useful architectural tool, too. And there are ways to use them that are even nicer than what most people tend to do.

Continue reading this post on PeakD.

The case for partials and pipes in PHP

Submitted by Larry on 23 June 2021 - 3:07pm

The Partial Function Application RFC is currently in voting, and right now it's a close vote to the negative. I wanted to take this opportunity to try and make the broader case for partial application and for its related RFC, the pipe operator, in a way that is more appropriate for a blog post than the RFC body (which is, by design, more concerned with the finer details of "what").

The main pushback on the RFC so far is that the benefits don't outweigh the cost of yet-more-syntax in the language. Which is a fair position to hold, albeit one I hope to convince you is incorrect. That is, I believe the benefits vastly outweigh the syntax and implementation cost.

Continue reading this post on PeakD.

Good technical writing is hard

Submitted by Larry on 31 May 2021 - 8:07pm

A few days ago, I randomly tossed this out on Twitter without context:

Technical writing requires assuming the reader is simultaneously highly intelligent and utterly ignorant, without making them feel like you think they're utterly ignorant.

That shit is hard, yo.

Someone asked for ideas on how to achieve that goal, and it seemed like a topic worthy of discussion so here we are.

Technical writing is not for Dummies

I would expand the statement above a bit, actually. Good technical writing requires: