But a scripting language needs an interpreter, they said. Not anymore! PHP still can't be compiled for real, there is a trick you can use.

TL;DR

• There is a project crazywhalecc/static-php-cli that allows you to compile PHP statically.
• Under the hood it uses dixyes/phpmicro – it is a special static PHP binary which you can “glue” to any PHP script.
• What remains is to build the application in PHAR and attach a statically-compiled interpreter binary to it.

Show me the code!

Here's a minimal PoC.

First, let’s download a pre-built phpmicro binary from the static-php-cli website. Since I’m on macOS, I’m using the following link:

curl -O https://dl.static-php.dev/static-php-cli/common/php-8.2.10-micro-macos-aarch64.tar.gz

tar -xvf php-8.2.10-micro-macos-aarch64.tar.gz

Now let’s create a simple application in index.php:

<?php

echo "hello world";

And we are ready to glue it with a PHP binary:

cat ./micro.sfx index.php > indexbin && chmod 0755 ./indexbin

And voilà! Run it:

./indexbin

PoC is nice, but will this work for real CLI applications?

Yes, but there may be challenges.

For a real CLI app, you would most likely need to pack the app in a PHAR file. For this, you'd typically use box-project/box.

I successfully created a basic "hello world" application with this method. You can find it in this repo: github.com/pronskiy/phin

However, when I attempted to integrate something more substantial like symfony/console, I encountered an error:

zend_mm_heap corrupted
Abort trap: 6

It looks fixable, but I haven't looked into exactly what causes it yet.

There will probably be other difficulties with more complex applications.

What about platform support? Linux / macOS / Windows ?

In the PoC above, I just download the phpmicro archive from here: https://dl.static-php.dev/static-php-cli/common/

But for real-world applications, you would want to build it on a CI for all platforms at once.

Micro-php is compatible with the popular Linux, macOS, and Windows platforms. Yet, as of now, GitHub Actions doesn't offer free builds for the ARM architecture, like macOS on M1/M2. But alternative CI/CD providers are available, or you could opt for a paid solution.

On a side note, pooling resources in a single repository to fund micro-php builds might be a viable solution. ;-).

Future prospects of this method?

Ideally, all of this can be organized as a ready-made GitHub Action, which you simply add to your repository, and for each release of your CLI-app you will get binaries for all platforms. Users would be able to download and use your CLI binaries without additional dependencies.

Static-php-cli is used in FrankenPHP. Notably, Kevin Dunglas, the author of FrankenPHP, actively contributes to static-php-cli.

#[<T>]
class Stack
{
    public function push(#[<T>] mixed $item): void
    {
    }

    public function pop(): #[<T>] mixed
    {
    }
}

Native generics. Will they be in PHP or not? Does PHP need them at all? We'll leave this speculation for the next time, but today let's discuss what generics might look like in PHP attributes.

Status-PHPDoc-quo

Nikita Popov did a comprehensive research on generics in PHP and shared detailed results here. Nikita also wrote a summary on Reddit during an AMA with the PhpStorm team:

The conclusion that Nikita came to is that there are only three ways to implement generics, and none of them will work in PHP. Or rather, it is possible to implement them, but each of them has significant drawbacks.

Nevertheless, the implementation of erased quasi-generics already exists today. I'm talking about PHPDoc annotations.

Although there is no official standard, the popular static analyzers PHPStan and Psalm, as well as PhpStorm, support a syntax that can generally be called well-established.

What prevents people from using generics via annotations? I just posed this question on Twitter. They are, after all, essentially erased generics, pretty much like in Python, for instance.

There were some constructive and substantive concerns raised in the replies:

Nothing stops me from using phpdoc generics, & I use them, but without native language support, I can?t enforce them on downstream users of my libraries, so I still have to write a lot of validation code to check types.

I think this would also be a problem with erased generics.

— Ben Ramsey @ramsey@phpc.social (@ramsey) October 18, 2022

There were also comments about the usability of such generics. But what annoys me, and what the Twitter mob didn't note, is that in modern PHP code you have to use both attributes and PHPDoc annotations simultaneously.

Generics, why no attributes?

The PHPDoc annotations are unstructured strings. They were meant to be replaced by attributes, which are part of the language, and set a strict format for metadata in PHP.

However, in the case of generics, the attributes look terrible:

/** @template T of object */
class Queue
{
    /** @var array<int,T> */
    private array $queue = [];

    /** @param T $item */
    public function add($item): void {}

    /** @return T */
    public function next() {}
}

// The same with current attributes => 

#[Template("T", "object")]
class Queue
{
    #[Type("array<int,T>")] 
    private array $queue = [];

    public function add(#[Type("T")] $item): void {}

    #[Type("T")]
    public function next() {}
}

In addition, the attributes only work on declarations but not on call-site. Consequently, you cannot do this:

/** @var Queue<Person> $personQueue */
$personQueue = new Queue();

// The same with current attributes =>

#[Type("Queue<Person>")]
$personQueue = new Queue();

Generics in attributes syntax RFC

What if generics looked prettier but remained in attributes?

#[<T>]
class Stack
{
    public function push(#[<T>] mixed $item): void
    {
    }

    public function pop(): #[<T>] mixed
    {
    }
}

Pros:

• PHP code remains untouched and BC breaks are not added
• The code becomes cleaner and prettier (subjectively)
• Static analyzers work as with PHPDoc
• Information about generics is available in the language itself (!)

Cons:

• Type information still in two places
• Hacky syntax (?)
• What else?

Why not all the way native generics with <T>?

Adding native erased generics we get to the inconsistency that some types are not checked at runtime. The attributes never gave a promise to change runtime behavior.

But what about runtime checks?

Since generics information is contained in attributes, it is available at runtime! This means that type checks can be implemented in userland in PHP. Such checks will probably be slower than the native ones, but the main advantage is that they can be entirely optional!

That means you can have early runtime checks in your local and test environments. For production you can disable such runtime checks and get performance boost there.

🚧 Static Analysis PoC

Here is a fork of Nikita's PHP parser that demonstrates this concept. And here is the PHPStan fork with the ability to use this syntax.

What do you think?

• How do you like this syntax?
• What problems do you see with this?
• What are other benefits and drawbacks?

Many thanks to Dave Liddament whose talk at the International PHP Conference in Munich inspired this idea. It literally came up during our discussion after Dave's talk:

It seems PHP generics is a hot topic at the moment. @pronskiy following on from our conversation at IPC, has the syntax #<> been suggested?

Would this work for adding type information for static analysis?

See more in gist: https://t.co/IOzSGgt1Xo

1/n https://t.co/BHkqP3cr07 pic.twitter.com/g2eIzm1ndT

— Dave Liddament (@DaveLiddament) October 30, 2022