[RFC] Four Pragmatic Directions for PHP: Simplicity, Arrays, Performance, Concurrency

// Current
$names = array_values(array_filter($users, fn($u) => $u->active));
$first = count($names) > 0 ? $names[0] : null;

Not the best example, as you can also do:

$first = array_find($users, fn ($user) => $user->active)?->name;

There are some existing functions like array_column() and array_first()
that seems you didn't know existed. So, there's been some progress in
this territory too.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

// Proposed
$names = array_pluck($users, 'name');
$names = array_where($users, fn($u) => $u->active);
$first = array_first($users);
$grouped = array_group_by($users, 'role');
$compact = array_compact($data);

Of those, array_compact() is obscure in its purpose, and of the others
one exists under the suggested name and three of the others exist under
different names.

array_group_by() is the only one that isn't already implemented. I think
it means:

$roles = array_unique(array_column($users, 'role'));
$grouped = array_combine($roles, array_map(fn($r) =>
array_filter($users, fn($u) => $u['role']==$r), $roles));

though there are more efficient (and readable) ways of doing that.

--

Optimising the implementation would be more difficult if the language
were allowed to be sloppier. Conversely, tightening up the language
allows improved optimisation.

Hi internals,

I'm a developer who uses both Java and PHP regularly. I'm writing
because I care about PHP's future.

PHP's strength has always been simplicity and pragmatism. But since
PHP 7 and especially PHP 8, we've been adding "enterprise features"
(typed properties, attributes, property hooks) that make PHP more like
Java – without achieving Java's type safety or ecosystem.

I believe PHP should refocus on what made it great. Here are four
pragmatic directions:

---

1. Stop Chasing Java

Every "enterprise feature" pushes developers like me toward Java. Not
because Java is better, but because if I need enterprise complexity
anyway, I'd rather use a language designed for it.

PHP cannot beat Java at its own game. But it can beat Java where it
matters: rapid prototyping, simple deployment, web-native development,
low learning curve.

Please keep PHP simple. Keep it pragmatic.

This accusation has been thrown at PHP every few months since PHP 5.0 came out (which did indeed ape Java 2 for much of its OOP syntax and behavior). It's really a farcical misunderstanding of language design, "enterprise features," and "pragmatism."

Many of the features added in the 8.0+ era are simple syntactic sugar to reduce typing. Is that "enterprise?" Typed properties greatly reduce the amount of error handling needed, and the amount of tests needed. Is that "enterprise?" Property hooks vastly reduce the need for boilerplate code, making it faster and easier to bang out code that is forward-compatible. Is that "enterprise?"

The programming language community at large keeps learning, and has learned a ton since the 90s. One thing it has learned, but many developers have not, is that "code that finds errors for you at compile time" is NOT an enterprise feature. It's an everybody feature, which is why virtually every untyped language has had some form of types added to it, in various ways. (PHP directly, Python via unenforced annotations, Javascript via TypeScript, etc.)

2. Add Practical Array Helpers

PHP is a web language – 90% of what we do is manipulate arrays. Yet
basic operations are still verbose:

// Current
$names = array_values(array_filter($users, fn($u) => $u->active));
$first = count($names) > 0 ? $names[0] : null;

// Proposed
$names = array_pluck($users, 'name');
$names = array_where($users, fn($u) => $u->active);
$first = array_first($users);
$grouped = array_group_by($users, 'role');
$compact = array_compact($data);

These helpers would make everyday code cleaner without adding
complexity.

You may have noticed that a number of array and string helper functions have been added in recent years. If there are more that you feel should be, RFCs are welcome. Just adding an array function is probably one of the simplest technical RFCs to write.

1. Improve Performance

Performance has always been a strength. Keep optimizing:

• JIT for real-world web workloads

• Reduce memory allocation in array operations

• Make OpCache smarter

All of these are happening, to the extent possible.

1. Provide Built-in Concurrency (Without Complexity)

Concurrency is the biggest missing piece. But instead of complex
async/await or coroutines, consider a simple worker management API:

php
$server = new WorkerServer();
$server->onWorkerStart(fn() => loadApp());
$server->onRequest(fn($req) => handle($req));
$server->start(4);
This would:

• Run standalone: php server.php – no nginx, no PHP-FPM

• Keep process isolation (each worker is separate)

• Allow resource initialization once per worker

• Give developers control without new concepts

Why not just use FrankenPHP? FrankenPHP is excellent, but requires an
additional binary and new deployment workflow. Many developers just
want a simple, built-in way to run their app without configuring two
services.

You may not have noticed, if you're new to the list, but there has been an extensive and ongoing discussion of improved async support, with a lot of focus on how to make it easy to use right and hard to use wrong. Because that is actually a really, really hard problem space. "Simple worker management" is not actually simple, when you dig into it. There's a lot of things that can go wrong, and designing it (both the code and the APi) such that it's hard to have things go wrong is itself really hard. That's why it's going on over a year now.

Rest assured, there's an awful lot of people that really want good async/workers/etc. But it's nowhere near as easy as you think, or it would be done already. (See also: generics.)

--Larry Garfield