As mentioned back in part 1, PSR-14 splits the core mediator into two objects: The Dispatcher and the Provider. The Dispatcher is fairly straightforward and most implementations will be fairly simple and fairly similar.
Providers are the exact opposite; A Listener Provider has one requirement: It maps the Event object into an iterable of callables, in the order it chooses. How it does that is left up to the Provider to define, and there are dozens of possible ways.
In the last installment we discussed the overall structure of PSR-14. Today I'd like to dive into the key aspect of any event system: The Events themselves.
Various different event systems structure events in different ways. Some require that it be an object. Others it's any arbitrary value. Others it's any number of arbitrary values, depending on the Event. Some really really want pass-by-reference arrays.
For PSR-14, we chose to standardize on an object and always an object. There were three main reasons for that:
The PHP Framework Interoperability Group (PHP-FIG) has released a number of new specifications in the last year. The latest, PSR-14, covers Event Dispatching. Like many PSRs it's a fairly small spec, at the end of the day, but intended to be high-impact.
In this series of posts I want to cover what PSR-14 is and does (and what it isn't and doesn't), and how to best leverage it in your projects as it gets deployed more widely.
It is trendy these days to extol the virtues of remote working, and either implicitly or explicitly shame any company/manager that doesn't like it. While there are absolutely advantages to remote work or working from home, the one-sidedness of the conversation is, I believe, actively harmful. The idea of "going to work" is still a valid and useful one, and one that should not be cavalierly cast aside in Twitter snark the way it currently is.
I don't know exactly when I started writing PHP. It was shortly after the start of my second quarter of my freshman year of college, when a newly-met friend of mine introduced me to PHP as an easier to understand alternative to Perl. That puts it, I think, somewhere in January or February of 1999.
20 years ago, give or take a week. I have been writing PHP for two decades. That's more than half my lifetime. I feel old.
I thought it would be amusing (mostly at my expense) to look back a bit on just how much the PHP world has changed in the last two decades.
When I started writing PHP:
At a hackathon at the Madison PHP 2018 conference, on a lark I made a quick port of the classic ELIZA chatbot therapist to PHP. (It made sense in context, trust me.)
After a little further cleanup I'm happy to announce that it's now fully released on Packagist and just a quick composer require away!
For those not familiar with it, ELIZA was one of the very first natural language processing programs. By which I mean it runs a few regexes over text strings in order to pick a response that makes it sound vaguely like a real therapist, if you turn your head and squint and have never met an actual therapist. (With due apologies to the actual real therapists out there.)
(I'm sure that's a bunch of gibberish for the non-developers in the room, but it matters to the PHP developers, I swear...)
After a longer than intended delay, I'm happy to announce the 3.0 release of my Crell/ApiProblem library.
ApiProblem is a small, self-contained library for modeling IETF RFC 7807 "Problem Details" messages. (I know, more gibberish.) That is, it makes it easier for PHP developers to build a message for their API servers to handle cases where Something Bad Happened(tm).
I was asked by php[architect] a while back to review "Functional Programming in PHP, 2nd Ed" by Simon Holywell. I've been sitting on this review for a while, so it's time to finally get it done.
I am all for testing. Whether you always write unit tests in advance as Test Driven Development (TDD) advocates call for, write them after, write them alongside, a little of each, I don't care. Tests are your friend. You want tests, and specifically you want good tests.
There's a lot of opinions on what constitutes a "good" test, of course, and much is subjective to the type of code you're working on. However, since the release of PHP 7 I've found that while writing tests... I am never using a mocking library. In fact, I'm going to go as far and say that
You should never use a mocking library in PHP 7.
Before all of you gasp, clutch your pearls, and send ninja hit squads after me, let me justify that position.
Let's be controversial: In modern PHP, you should never type-hint an array.
Before you start throwing tomatoes, hear me out.
PHP allows you to specify the type of a function/method parameter or return value. These return values can be any legal PHP type, which includes any class or interface type, various scalars, and some fancy pseudo-types like callable and iterable.
PHP has a data type that it calls array, although it's not really an array as any other language would define it. It combines what most languages would call a vector (a sequence of variable length) with a dictionary (a list of key/value pairs). As a result, it often gets used as a cheap anonymous struct for complex data that the developer feels isn't worth defining a class for.
And you should almost never use array as a type hint. Why? Because there's always a better, more generic option.
Let's consider three cases: