Code profiling tools are everything now.

When I was staring at Thaura writing code, it was doing some wild tricks with python and grep and other unix tools that I’d never seen before.

So I told it to write tools to do simple kinds of code analysis, to help map out and index the code. I also wrote scoreboard database tools, to keep track of work to do, and work completed. I had it put the code analysis info into the database, too.

I also asked it to tell me about all the PHP static analysis tools, and enlisted them all into the programming process: linters, code stylers, static type analysis.

The LLM can use these tools the way we use them, to understand the code, and to demonstrate that code conforms to some idea of “order”.

The LLM also uses them as a kind of debugging aid, or a pre-run tester.

I also leaned on Playwright and the old reliable PHPUnit.

Illusions of Complete Coverage, and “AI Psychosis”

The problem with these code analysis tools is: they don’t enforce writing good code as much as assist with it. They mainly help when the code is big enough to forget parts of it.

They give you the illusion of total control, when you’re just keeping things together.

Likewise, the LLM will appear to be making great, sweeping changes over the code, but touching only a fraction of it, leaving lots of code untouched, and report back with a chat message that it did a lot of work.

The LLM straight up bullshitted the boss!

I totally fell for it.

The problems would trigger errors and warnings, and then the LLM would look at the errant code, and go fix it, with some chatter about how it was still doing the old thing, when it should be doing the new thing.

Then it was fixed, passed the test, looks good in the analysis tools, and the LLM moved on, and I moved on.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 5 first appeared on 🍙.

Continuing the series, more info about altering project internals.

I think of this like a caterpillar going into a cocoon, having enzymes totally disintegrate its guts, and then produce a butterfly, which will go out and mate with other butterfiles. It’s a metamorphosis. Except, with this software, you don’t see any visible changes once it’s changed.

So that’s not a good analogy.

Maybe it’s more like an electric car, which looks as ugly as the gasoline cars, or even worse, but has completely different insides. It’s better on the inside.

Another bad analogy.

It’s like you shoved a seed into a pile of manure, and it’s started to grow, but you still can’t see the plant. It just looks like a pile of shit. But there’s good stuff in there.

Yes, that’s it.

I’m going to do another release of software.

I’ll just call it r2 or release 2….

Here’s what happened. It took all day. The reasons were noted in the email I sent out, but the actual delays were as follows:

The instructions that the LLM wrote were not easy to understand. In retrospect, I should have just hand-written them.

(Then, those notes could have become part of the LLMs knowledge, and could have influenced it to write better documents.)

Cloning the database was smooth, but getting the live database container updated to a newer version of MariaDB took extra time.

Cloning the release from Git was quick. Moving it into place was quick. (Name the new clone directory blahblah.new, then mv blahblah to blahbla.old, then mv blahblah.new blahblah. Restart Nginx, restart the php container.)

Configuring the Nginx proxy took a LOT of effort, because I did it too soon. The examples the LLM created were wrong, as well, but had enough info that I could make it work.

Reconfiguring the containers to run the app was pretty simple, but I had forgotten that I changed the paths where I wanted the files mounted. This sent me down some rabbitholes related to Nginx config. (I should have held back on changing Nginx.)

Overall, it wasn’t that bad, except for the Nginx configuration.

A New, Nonfunctional API

I made an API to feed the mobile app, and it didn’t work. Digging into the code, was a minor horror. The LLM wrote code well, but the overall “separation of concerns” and keeping the code in the right places, wasn’t so great.

I forget what the fix was, but it eventually worked. It was a combination of fixing some obsolete SQL code, and making an Nginx config.

PHP Attack Scripts

The PHP security hole drama has led to a bit more attack against the sites, particularly scans for remote shells written in PHP.

That just overloads the server, even when the scripts aren’t there.

So I had to do some tricks to detect these requests, and block them. This took a few hours.

Get Rid of phpinfo()

If you’re running PHP in a container, and use .env to pass passwords into your container, it’s critical to find and remove all instances of scripts that use the phpinfo() function.

That function dumps the environment variables to the page, leaking credentials. This command will recursively find the string “phpinfo” in all your files.

grep -r phpinfo *

Archives

One of my big goals was to get the site into shape for archving. This entails being able to easily download the entire site, using tools like wget.

Generating HTML files as final output is one step toward this goal. While archivers handle .php file endings, they like .html more, and with .html, you can view archives with a plain web browser.

With .html files, you can “archive” by copying over all the files. You won’t need all this software to operate the archived site.

Indexes

Generating complete indexes to the news articles and events allows webcrawlers to get at everything.

This is also a risk, because lots of bots are out there scraping the site, and a complete index will potentially increase their downloading, and risk overloading the site.

Page generation helps with this, because serving up a generated HTML page takes a tiny fraction of the resources of running a PHP file. (Example: on an older computer, a very heavy site like WordPress can top out at 30 requests per second, while a similar HTML site can reach into the 10k requests per second.)

Bots I’ve seen scraping the site: Google, Bing, Claude, Baidu, OpenAI, Ahrefs, Yandex.

Twig Templates

To this end, instead of trying to change the page generation within the existing code, I had the LLM add Twig. It seemed to know more about Twig than Blade, so I went with Twig.

The LLM set up a parallel template structure that copied parts of the existing templates, and then ported the entire site to use it, but didn’t actually remove all of it, because some of the templates we had were full of PHP code.

The Twig templates mixed with the old template system are a mess; they’re completely enmeshed, to replicate the old site.

Eventually, almost the entire site will be generated with Twig.

Eventually, this will be replaced with new layouts that aren’t mixed with the old code.

I suspect I’m going to need to start the process by hand, writing my own templates.

Order and Memory Capacity

This did get me thinking about the issue of why we think some code is well organized, and some code is not.

Part of it is our limited capacity to comprehend large, complicated systems.

To handle big systems, we use structures, like lists, hierarchies, “black boxing”, making things modular, and using repetitive patterns.

The LLM, unlike people, has a different kind of “memory” or “attention” or capacity to deal with large amounts of information. So, while the code looks like a mess to me, it still makes sense to the LLM.

Here’s some computer code that vibe coding produced:

function rotated(p){ // rotate cells 90deg clockwise, re-normalize to 0
  const maxX = Math.max(...p.cells.map(c=>c.x));
  const cells = p.cells.map(c=>({x:c.y, y:maxX-c.x, ch:c.ch}));
  const minX = Math.min(...cells.map(c=>c.x)), minY = Math.min(...cells.map(c=>c.y));
  return cells.map(c=>({x:c.x-minX, y:c.y-minY, ch:c.ch}));
}

function rotated(p){ // rotate cells 90deg clockwise, re-normalize to 0
  const maxX = Math.max(...p.cells.map(c=>c.x));
  const cells = p.cells.map(c=>({x:c.y, y:maxX-c.x, ch:c.ch}));
  const minX = Math.min(...cells.map(c=>c.x)), minY = Math.min(...cells.map(c=>c.y));
  return cells.map(c=>({x:c.x-minX, y:c.y-minY, ch:c.ch}));
}

Almost any programmer has written code like that, but how many enjoy reading code like that.

Conversely, computer code is extremely brittle. A single character out of place, and parts may break. The LLM can write code, but more importantly, it can transform vague instructions and turn them into concrete goals, like people can. So it’s like a programming language that’s a human language.

The challenge is to get the LLM to conform to (the declining) human need to keep code organized, for human comprehension.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 4 first appeared on 🍙.

Continuing the series, more info about altering project internals.

I got so tired that I stopped blogging. A note to myself read:

The main big issues I’ve hit this time are refactoring introducing bugs bug repairs introducing bugs incomplete testing of outputs database export and import problems.

Refactoring Introducing Bugs

Initially, I wasn’t that aggressive about testing. I just used URLs and GET to test a list of pages, and told the bot to read the logs. It would find errors and warnings, and fix them.

Then, I got hit with a bunch of uncaught bugs.

One of them was a bug that I knew we corrected before.

So I decided that whenever I found a bug, I wanted a test generated that would prevent that bug from reappearing.

I’m guessing that a bug reappeared because the code was being refactored.

Refactoring is basically building a new code structure, and then copying your old code into it. When it copied the code, it wrote the bug back into existence.

Bug Fixing Revealing Bugs or Introducing Bugs

This isn’t an LLM issue per-se, but in dynamic languages, fixing a bug might reveal other bugs that, until then, were not found, because the first bug killed the program.

An automated test case helps with these.

Incomplete Testing of Outputs

I wish I could remember the situation, but Thaura did a big batch of changes, but it wasn’t testing the output. It just did the modifications.

Some early modifications had automated tests, and it used those to fine tune it’s behavior, but then, it just abandoned testing.

It seemed to be working so fast, so I asked if it was checking outputs. It wasn’t.

So, it’s good to ask the bot what it did. You can read it, and determine if the bot failed to do something. You can find tune its behavior.

Database Import and Export Problems

Initially, I tried to do a mysqldump from MySQL 5.7 and load it into MariaDB 11. It didn’t work, but I expected that. Not only that, but the data needed a lot of manual cleanup.

So I used an intermediate format, JSON, to dump the data, and load it in. That worked extremely well.

Then, I thought I could dump from the dev database and load it into the production database, like this:

No such luck.

They were both MariaDB 11, and the same point version, but different releases, and in slightly different operating systems (Alpine Linux vs. whatever MariaDB’s Docker package uses).

So I had Thaura write a filter to allow the dump to work, mainly by stripping some comments, like this:

(Claude screwed up the diagram. The first dump is a MySQL dump.)

Obviously, I should have focused on defining an intermediate data dump format that would work for us.

This isn’t a PHP porting issue, but it could come up.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 3 first appeared on 🍙.

Last time it was about updating code. Now it’s about altering project internals.

Mid-Project Legacy

A long time ago, I decided that the old style include(‘foo_class.inc’) was annoying, and the new style autoloader classes with use \Foo; were nicer.

So I did a simple thing: copy them all into a namespace, and then convert them to PSR-4 compatible classes (aka, autoloading classes).

I left the old files around, just in case they were still being used. The project never completed, and maybe around 10 classes were converted, and many were not.

I told the LLM to fix this, and make everything into a PSR-4 compatible class. It decided which version was good, and which was not and possible merges.

This is mind-blowing to me, that the program can do this.

The process took a day, due to pauses and usage limits, and I’m still not sure it’s OK.

The goal here was to allow static code checking tools like Psalm to do better code analysis.

So far, no real new code

I’m just writing this to make a weird point: I haven’t asked the LLM to write new code. It’s refactoring.

It’s making old code conform to newer programming standards.

It’s removing code, too.

Some Removals

Reporting bad posts – a system similar to Digg, where the community can moderate. It stopped being useful when people gamed it or it didn’t instantly mod someone down.

Spam trapping – I had a bunch of filters, some quite nice, but it was out of date.

IP logging and redirecting – this is still important, but the site’s implementation was pretty annoying, so it goes.

DIY captcha – I wrote it because there weren’t many options I liked. Now, it’s not that relevant because there are packages for captchas.

Themes – again, not super popular, and it was done in a annoying way, with GET parameters.

These removals aren’t all because the feature was bad, but it was just out of date, or should be replaced. Removing them helped reduce the code size.

Improving Debugging

After telling Thaura to do something a certain way, over and over, it starts to do it, automatically, and even expand on it.

I told it to use the static analysis and dependency databases a couple times, and it figured out how to use them.

I told it to always do static analysis and check dependencies, and it would do both, with the tools, and on its own.

So every change is checked with these tools, and also with the Playwright integration tests against some URLs. These can trigger warnings in the logs, so I have it read the logs and debug error and warning messages.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 2 first appeared on 🍙.

This document describes how I’m porting a legacy PHP codebase to PHP8.5. The security crisis of October 2026 required porting everything on a legacy website to PHP8, the only version that’s getting updated now. This document is in flux and will change as the port progresses.

The legacy code was running on two containers, behind a nginx reverse proxy, that directed most of the traffic to he PHP7 version of the code, but ran some very old code in PHP5.

The goal was to port code to PHP8, and implement a new app stack that’s nginx + php-fpm + php8.5.

The TL;DR:

• Lean on code linters first.
• Create infrastructure to organize the process of fixing individual files, to get them to compile. Don’t bother to fix the logic at this time.
• Tell the LLM to log changes.
• Build up the new codebase from the old (the LLM made this decision), linting the old PHP7 code mostly.
• Build up the new deployment environment by using the old config files.

The general progression of the work:

1. Download all the old code into a project.
   1. Make a git repo, and add lines to README to use it. (Helps the LLM undo things and see history.)
   2. Include relevant config files. (Teaches context. LLM should know all the parts, rather than assume anything.)
   3. Create careful database dumps, by table rather than the entire db. I had an old archiving tool for this, and used it. Download into repo.
   4. Write notes about the current architecture, project folder layout, db version.
   5. Tell the LLM to log changes to a changelog.
2. Update the code so it compiles.
   1. Use static code linters, stylers, deprecated code scanners, etc. to test the code. (Do not rely on the LLM’s reasoning. Ask it to recommend tools, and install them. Then, you need to configure them to work with your file layout, include paths, etc.)
   2. Let the LLM plan and make the code changes.
   3. Let the LLM guess about which files, and which versions, would need to be ported.
   4. The LLM had trouble running a batch script to do the tool calls, so I told it to make another batcher script to run the script over around 20 files. The LLM tells me to run it when it’s changed.
   5. Made mid-project decision to use a SQLite scoreboard to track the state of each file. Updated scripts to update the scoreboard. This makes the batching partially obsolete.
3. Make a Docker dev environment similar to the deployment goal. Use this to do the runtime integration tests.
   1. Playwright for integration testing.
   2. PHPUnit or similar for unit or function testing.

The llm

I’m using Thaura Pro. The pro is that it’s pretty cheap at $15 a month. The problem is that you can use it only 5 hours at a time, and then you have to take a break. I really don’t mind this.

The tool execution limit will trigger every 15 minutes or so, and require a button click.

Static Checkers

Linters and static code checkers run on the desktop computer to produce reports about code problems. These help you analyze lots of code without burning tokens (or dealing with the indeterminacy of LLMs).

The LLM should write the config files for these tools, so it can adjust them as it runs.

I started with report text files, and a batch file to produce them, but eventually added a sqlite based scoreboard to track work progress. The linting can happen in parallel with the LLM coding.

Coding is “slow”, at maybe 1 minute per file. That’s many multiples of how fast I code, but there is still some waiting. The LLM works in batches of 5-10 files.

A batch checker script, over time, became a kind of scratchpad for the next 10 to 20 files to test. Due to a security issue, I had to run this manually.

What’s nice about the scoreboard and the report.txt sidecars is that I can work in parallel with the LLM. I just write tools (by hand, or by LLM), use other LLMs to set up Docker, edit the README and other notes.

Even this static analysis phase is full of constant changes and improvements.

The Port Environment

The initial environment is a directory that looks like this:

src/
     db/ -- legacy data
     apache/ -- legacy config
     nginx/ -- legacy config
     php5/ -- legacy code
     php7/ -- legacy code
     php8/ -- ported code, goes into git repo
         sitename/ -- not the actual sitename
             local/ -- caches and local code
             public/ -- website root
             shared/ -- project-wide code libraries
bin/ -- scripts and tools to help with coding, goes in repo
docker/ -- configs and tools for docker containers, goes in repo
legacy-data/ -- not the actual name, but things like generated files, temp files, uploads, were downloaded into here, as samples. The entire site was not copied.

The main tools (at thist time) are syntax checkers, linters, like ‘php -l’, phpstan, psalm, phpcs. Helper scripts run the tools, load configs, query the scoreboard, etc.

Thaura can also run these tools individually.

Changes are logged in these places: CHANGELOG.txt, somescript.php.report.txt sidecars that record the output of the syntax checkers (so the LLM doesn’t need to run them individually), the git commits, and I write some changes into README.txt and then tell Thaura to read it. I think Thara also keeps a todo file on its server.

Legacy configs help a lot, explaining how the actual live app works. Porting proceeds breadth-first, and based on what’s exposed through these configs, particularly the nginx reverse proxy, which forwards traffic to two different PHP containers, depending on the URI.

The new config is much simpler, because it’s a single codebase. The old configs help the port avoid porting stray PHP files here and there, by identifying what is exposed to the world.

Early on, the LLM is just guessing which files are dependencies. This will come out in the wash and rinse as the code is executed.

Code Fixing

The first goal was to get all the code compiling. I didn’t care if it had some warnings, and I didn’t care if it even ran correctly.

This took over a day, but eventually finished.

Initially, I thought the next step would be to write tests, like TDD, but, instead, the LLM was going into actual debugging, so I went along.

This is almost like the opposite of TDD, and more like interactive programming with an interpreter.

I’d give it a URL, and tell it to fix it, by figuring out which files get loaded, and checking the work from the URL down to the libraries. It required checking dependencies.

Tests

So I did around 10 or 15 of these debugging excursions, and it got better at it over time.

Next, I told it to create Playwright tests for a bunch of the URLs, and some new ones.

More on this later.

Database Tables

During debugging, it would sometimes hit missing database tables. This could cause the LLM to go on a pointless debugging excursion, or try to recreate the table.

I’d have to stop it, ssh into the server, alter the table dumping script, exit ssh, and then do an rsync to copy the new table dumps.

The LLM created a couple utilities to upload the tables into the local DB.

MySQL 5.7 to MariaDB Migration

Initially, I thought it would work to use the db dumps to load MariaDB. It seemed like some python scripts could fix them up, since they use roughly the same SQL.

I hadn’t thought about the long term nightmare of migrating from latin1 to utf8, which the site underwent over many years. By and large, the data was ASCII or UTF-8, but many columns were typed as latin1.

So, instead, the LLM offered to fix some of the bad data, and I asked for tools to dump the data to JSON, and load the data from JSON.

The new tables and columns will, eventually, be utf8mb4, or whatever is best for the near future.

The data repair was pretty amazing. It didn’t just fix our internal migration mistakes – it also fixed dirty user input.

I could tell it had the accumulated experience of decades of annoyances people had when migrating to Unicode and UTF8.

Testing URLs

The LLM seemed to be really good at figuring out how a URL maps to a PHP file, and all the PHP files that get involved in producing that URL.

I also taught it how to go into the /admin/ area, with a username and password, and run the page generation code.

The code wasn’t really working, so during this “training”, it was also looking at the code and fixing it until it worked. Mostly, it was configuration issues.

So, now, I could tell it to fix something that involved page generation, and it could “drive” the site to regenerate the page during its debugging.

I settled into using this prompt pattern:

/path/to/url.php -- this page does this, but it's not doing it correctly. Debug it.

I repeated this for all the parts of the admin, including the parts I was hoping to remove.

Then I repeated it for world-facing pages.

I didn’t test if the site could upload files, etc. When I was creating the Playwright tests, it went ahead and wrote tests to do some of that.

So, with this interactive debugging, I suspect I primed the LLM to know how to make the Playwright tests.

Simplification by Replacing Variables with Constants

The site had two config files, and many of the configs were global variables.

Most of these were used like constants. They never changed.

So I told two LLMS to go, one by one, and replace the variable with a constant, if the variable wasn’t ever assigned a value elsewhere in the code.

Every variable is a potential decision point: an if statement, or switch statement, or concatenation in a string that’s a file path, etc.

Replacing variables with constants, when possible, should make debugging easier.

To test it, I used the big test suite in playwright, and told the LLM to run each test individually, and read the logs, fixing any errors or warnings.

Enabling Xdebug

I should have done this from the start, but better late than never. I had it produce dumps about what functions got called, and it also allows the LLM to do debugging.

Scoreboards and Dependencies

I had it create a scoreboard system to see how the code porting and conversion were progressing — the pass/fail status was determined by running static checkers on the code.

Then I created commands to query the scoreboard.

It eventually seemed to use it a little bit. I think doing the scoreboard from the start, could have helped, but, if anything, I got more use out of it than the LLM.

I also had it create a database of dependencies, of what files get included (and what files include a given file).

Tools for OOP in PHP will produce this info, but this codebase is mostly PHP4 style require() and include() based.

Again, I don’t know if the LLM used it, but it would have helped debugging go faster.

This is all debugging infrastructure, ultimately, and it’s good not only for the LLM but for the programmer as well.

Removing Features

The old software had a bunch of features that nobody seems to use anymore.

going forward, i want to do a commit before, and a dev release after, a site feature is removed, so it's easy to go back and undo a bad batch of work. for example, for this round, I'd like to remove code related to themes, theme.php and anything related to it, like CSS files, any gui related to the theme, and logic to switch the theme. Only the default theme should be left. analyze the code, plan the removal, and then remove, and test. then, remove any playwright tests for themes. when it's all good, do a dev release.

going forward, i want to do a commit before, and a dev release after, a site feature is removed, so it's easy to go back and undo a bad batch of work. for example, for this round, I'd like to remove code related to themes, theme.php and anything related to it, like CSS files, any gui related to the theme, and logic to switch the theme. Only the default theme should be left. analyze the code, plan the removal, and then remove, and test. then, remove any playwright tests for themes. when it's all good, do a dev release.

I know the codebase pretty well, so I knew this was a pretty simple change.

Removing features removes files, and removing files reduces the amount of context required to edit the code.

Code that would use the theme variable was also rewritten to simply use the default theme.

(My plan is to re-add features by using external libraries when appropriate.)

Continued in part 2.

The post Thaura: Porting Legacy PHP5 and PHP7 Project to PHP8 Part 1 first appeared on 🍙.

https://generalistprogrammer.com/tutorials/php-traits-complete-guide

Thinking out loud… tell me if I’m wrong.

I’m mulling the idea of using Traits to compose static classes with no state.

The static class would act as a Facade. It could implement an Interface.

The static class would be paired with a state object, which could contain all the state. This pairing would allow a clean separation of data from algorithms.

The Traits would contain no state. State, or portions of state, are passed in as parameters to methods.

Maybe it would be possible to create no-state objects, to allow for class-based dispatch (a kind of polymorphism).

Notebooking

This is the first draft. It worked, but it it useful?

<?php

interface AnimalInterface {
    static function sayHello(Animal $a);
    static function doPoo(Animal $a);
    static function doEat(Animal $a);
}

class Animal implements AnimalInterface {
  use Speak;
  use Poop;
  use Eat;
}

trait Speak {
    static function sayHello(Animal $a) 
    {
        echo 'Says: ' . $a->speech . "\n";
    }
}

trait Poop {
    static function doPoo(Animal $a)
    {
        echo 'Defecates: ' . $a->defecate . "\n";
    }
}

trait Eat {
    static function doEat(Animal $a)
    {
        echo 'Eats: ' . $a->food . "\n";
    }
}

class AnimalState {
    public $state = [];

    function init() 
    {
        $this->state['dog'] = new Dog();
        $this->state['cat'] = new Cat();
        $this->state['bird'] = new Bird();
    }
}

class Dog extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'woof';
        $this->defecate = 'dog loaf';
        $this->food = 'kibble';
        $this->age = $age;
    }
}

class Cat extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'mew';
        $this->defecate = 'hairpoo';
        $this->food = 'tuna';
        $this->age = $age;
    }
}

class Bird extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'chirp';
        $this->defecate = 'birdstool';
        $this->food = 'millet';
        $this->age = $age;
    }
}

$s = new AnimalState();
$s->init();

echo "\ndog\n";
Animal::sayHello( $s->state['dog'] );
Animal::doPoo( $s->state['dog'] );
Animal::doEat( $s->state['dog'] );
echo "\ncat\n";
Animal::sayHello( $s->state['cat'] );
Animal::doPoo( $s->state['cat'] );
Animal::doEat( $s->state['cat'] );
echo "\nbird\n";
Animal::sayHello( $s->state['bird'] );
Animal::doPoo( $s->state['bird'] );
Animal::doEat( $s->state['bird'] );

// we create a new bird to replace the old one
$s->state['bird'] = new Bird(5);

echo "\nthe new bird has age: " . $s->state['bird']->age . "\n\n";

var_dump($s);

<?php

interface AnimalInterface {
    static function sayHello(Animal $a);
    static function doPoo(Animal $a);
    static function doEat(Animal $a);
}

class Animal implements AnimalInterface {
  use Speak;
  use Poop;
  use Eat;
}

trait Speak {
    static function sayHello(Animal $a) 
    {
        echo 'Says: ' . $a->speech . "\n";
    }
}

trait Poop {
    static function doPoo(Animal $a)
    {
        echo 'Defecates: ' . $a->defecate . "\n";
    }
}

trait Eat {
    static function doEat(Animal $a)
    {
        echo 'Eats: ' . $a->food . "\n";
    }
}

class AnimalState {
    public $state = [];

    function init() 
    {
        $this->state['dog'] = new Dog();
        $this->state['cat'] = new Cat();
        $this->state['bird'] = new Bird();
    }
}

class Dog extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'woof';
        $this->defecate = 'dog loaf';
        $this->food = 'kibble';
        $this->age = $age;
    }
}

class Cat extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'mew';
        $this->defecate = 'hairpoo';
        $this->food = 'tuna';
        $this->age = $age;
    }
}

class Bird extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'chirp';
        $this->defecate = 'birdstool';
        $this->food = 'millet';
        $this->age = $age;
    }
}

$s = new AnimalState();
$s->init();

echo "\ndog\n";
Animal::sayHello( $s->state['dog'] );
Animal::doPoo( $s->state['dog'] );
Animal::doEat( $s->state['dog'] );
echo "\ncat\n";
Animal::sayHello( $s->state['cat'] );
Animal::doPoo( $s->state['cat'] );
Animal::doEat( $s->state['cat'] );
echo "\nbird\n";
Animal::sayHello( $s->state['bird'] );
Animal::doPoo( $s->state['bird'] );
Animal::doEat( $s->state['bird'] );

// we create a new bird to replace the old one
$s->state['bird'] = new Bird(5);

echo "\nthe new bird has age: " . $s->state['bird']->age . "\n\n";

var_dump($s);

This code has interesting qualities.

First, the AnimalState is the only thing that holds state.

Everything else doesn’t hold state.

The Dog, Cat, and Bird types are stateful classes, and instantiated, but aren’t mutable. All the properties are readonly.

Look at line 109. I cannot set the value of $age, because it’s readonly, but I can initialize a new Bird of 5 years old. Some languages also have this restriction, where named values are immutable.

Method names and property names matter. For all the parts to work, they must conform. The AnimalInterface enforces the method names. Nothing enforces the property names.

Is it useful? I’m not sure. It’s a lot of extra boilerplate.

What’s Missing?

PHP 8.3.6 doesn’t support public readonly protected(set). If it did, I think I could move the variable declarations up into Animal, and it would act like a contract for the subclasses.

I tried moving the properties like $speech into the Trait (rather than in the Class like it is above). It linted with php -l, failed with phpstan, and didn’t run. It refused to initialize the $speech property from the Trait because it was out of the Dog scope.

Here’s the json_encode($s) output:

{
    \"state\": {
        \"dog\": {
            \"speech\": \"woof\",
            \"defecate\": \"dog loaf\",
            \"food\": \"kibble\",
            \"age\": 1
        },
        \"cat\": {
            \"speech\": \"mew\",
            \"defecate\": \"hairpoo\",
            \"food\": \"tuna\",
            \"age\": 1
        },
        \"bird\": {
            \"speech\": \"chirp\",
            \"defecate\": \"birdstool\",
            \"food\": \"millet\",
            \"age\": 5
        }
    }
}

It’s OK, but it needs a _class property so it can rehydrate correctly (which is easy to add).

$s->state['bird']->age = 100; // this code passes php’s lint, but it’s a bug.

Ideally, this bug would be caught at compile time, because assigning a value to a readonly property throws an error when run.

I found this good post about PHP linters.

phpstan found the bug with –level 3.

(I tried installing psalm, but my PHP version was too low.)

More Thinking

In a real-world scenario, you would probably have a more elaborate state structure of nested arrays, terminating in these read-only objects, or arrays of read-only objects.

Your application would be a bunch of Interfaces and implementation, read-only objects, and some logic to make the app happen.

I think you’d have lots of code like this:

$s->state['x']['y']['z'] = 
    SomeService::doAThingTo( $s->state['x']['y']['z'] );

You’d have that mixed in with a lot of traditional logic.

You’d write functions to manipulate the state yourself.

Some things could get easy, like saving the app state with each request: use a flatter namespace, and save it to Redis. (Examples: ‘config’, ‘app’, ‘user’, ‘documents’.)

Retrieve the state from Redis. Add a feature to lazy-load the data, and write subsets of the state.

AnimalState doesn’t need to be initialized with objects. It’s just an array. It should probably use magic methods to allow $s->dog to return the Dog object.

Setter magic methods could verify that the new value is of the same class as the old value; so a Dog object must be replaced with another Dog object.

DocBlocks might be able to add a type annotation, but I don’t know if it would be honored.

Magic getters could map a key like ‘dog’ to a property named ‘_dog’, which has a type signature that phpstan might recognize. The magic getter should be coded up with a switch statement rather than doing string mangling and isset().

Example:

public readonly Dog $_dog;

function __get($key): Animal
{
    switch($key) {
        case 'dog': return $this->_dog;
        default: // some error situation, die nicely
    }
}

The robot overlords can understand that code path, and won’t need to “reason” about some string mangling code like this (code not checked):

public $state;
...
function __get($key): object 
{
    $kkey = "_$key";
    if (isset($this->state[$kkey])) {
        return $this->state[$kkey];
    } else {
       // die politely
    }
}

I realize the latter is more general, but that begs the question: should everything be generalized and flexible at runtime, even if it’s the thing holding the application state?

The answer in 2026 is “no”.

The post PHP Traits first appeared on 🍙.