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:

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!

Continue reading this post on Steemit

Recently I was working on some PHP code (for the PHP-FIG) that involved code generation. Lots of systems these days are doing code generation (compiled dependency injection containers, ORM classes, etc.), but surprisingly I've avoided having to touch that code myself until now.

Of course, like any good developer I was writing tests for it as I went. That meant needing to test that the generated code was valid PHP syntax and did what I wanted it to do.

(Continue reading this post on Steemit.)

One of my favorite podcasts is Make Me Smart, hosted by public radio's Kai Ryssdal and Molly Wood. It's part of the Marketplace family of shows by American Public Media and is a friendly, casual look at the "big picture" of many of the stories of the day. One of their running themes is the "Make Me Smart question" that they ask everyone they interview, and encourage listeners to write or tweet or vlog in with their own answers to:

What is something you thought you knew that it later turned out you were wrong about?

It took me a while to decide what my own answer to that would be, but when I finally did I realized it was going to be way too long for a tweet to explain, so here we go.

Recent events in the PHP community in the past few days have reminded me of an important point that bears repeating. Quite simply: There are always community standards, and if you are not upholding them then you are actively undermining them.

One reason to follow development mailing lists is you sometimes pick up on some very neat tricks. Here's one that I spotted on the PHP Internals list recently to simplify array iteration in PHP 7.