That would be great. To be honest, the biggest bang cod the buck would be switch_global_context. Just that alone can turn all existing php code into something that can be adapted to evented programming (amPHP, reactPHP, Swoole and FrankenPHP).
As it is, only Latavel Octane and a couple other projects have dared to redo everything. And the reason is all the static functions, static vars, global vars, superglobals etc. If one can just switch global contexts with switch_global_context as easily as they can switch sessions with session_start, that would be a game-changer. Of course then we have the question of too many contexts in memory at once, so we do need to serialize them to disk, and that’s where I think encryption-at-rest can be transparently introduced, with a key specified at start. It can also be re-used for storing session data and lots of other data. Just another example of PHP nicely taking care of things for us (like it automatically hydrates the superglobals for us etc.) This is idiomatic PHP, it is shared-nothing and is the only web hosting runtime that’s actually safe by default — safe from leaking secrets, memory, etc. across requests. These two functions can keep it that way, leveraging all the code that’s already been written assuming shared-nothing (php-fpm) and making it work in the evented paradigm, where leaks can happen. If we do this, I can see php developing an ecosystem of asynchronous drivers just like node has, for I/O with callbacks (using select() underneath in POSIX systems for example). Already the amphp and other ecosystems have the basics: https, mysql, etc. But the advantage would be that PHP would remain safe, by having devs build on all the existing code that relies on its shared-nothing architecture (from Wordpress to Drupal to Magento to Joomla to our platform etc.) and just making it 10x faster and evented Until then… I guess I’ll just use curl_multi and batch requests together clunkily through closures. Sincerely, Greg Magarshak https://github.com/Qbix On Thu, Jul 31, 2025 at 5:15 AM Alexandre Daubois < alex.daubois+...@gmail.com> wrote: > > Thanks for the suggestions. Maybe add a new function > func_get_named_args(): array<string, mixed>, would be a good extension to > the named arguments rfc. > > I even wonder if this would require a RFC? If not, this is something > that may be proposed for PHP 8.5. > > Best, > Alexandre Daubois >
