Re: Three proposals for PHP 9

> Gregory Magarshak <greg@qbix.com> hat am 29.07.2025 19:46 CEST geschrieben: > > > I came across this post on Reddit asking what people would like to see in the next PHP: > https://www.reddit.com/r/PHP/s/l9r8UJP6Rk > > There are two major proposals I would make, both of which aim to greatly improve PHP's > competitiveness and ecosystem, while maintaining its spirit and what makes it great. And one minor > proposal. I wrote them on Reddit, but then I realized I should actually do something about it. The > last time I did something was in 2015 writing to the PHP list back then. > > How do I get rights to create my own RFCs for these? I tried to do it on the web, but it says > to ask on the mailing list. Here are my bona fides: I've spent about 20 years with PHP, to be > honest, and the last 14 building an open-source community platform / CMS that competes with > Facebook, Twitter, etc. and uses very idiomatic PHP. Here are two links in case anyone is interested > https://github.com/Qbix > https://www.laweekly.com/restoring-healthy-communities/ > > Anyway without further ado, I would like to present the two proposals: > > First one: introduce switch_global_context($name) > ============ > > I really love PHP’s shared-nothing architecture, but when it comes to frankenphp, swoole etc. > it is very hard to port existing apps to that evented runtime. That is mainly because the > superglobals and static variables are — well — global. You can have the best of both worlds. > > Just add a function to PHP which can do context switching between all global scopes, to any > named scope. So when you have one evented runtime, it can quickly switch. This should be easy to do > with SHM (shared memory segments) and just pointing to a different page in memory. > > The goal is to allow all “legacy” code (ie all current PHP code that runs on php-fpm etc) > to be trivially ported to much faster runtimes, while remaining “shared-nothing” for all intents > and purposes (global contexts would be isolated from one another because only one could be active at > a time). > > Second one: set_encryption_seed($name) > > You might need to let people register functions to run before a context is saved (sleep) and > after it is loaded (wakeup), when there is memory pressure, PHP can handle this in a standard way > and even encrypt it at rest. You can also do this for session save/open handlers (which you already > do). > > Just have an environment variable or function like set_encryption_seed($seed) at startup of > frankenphp or swoole. > > Third one one: Improve func_get_args to return associative arrays. > =================== > > I had this suggestion back in 2015 but maybe now it’s outdated. You see, functions typically > start out having required arguments first, then add on optional arguments later. I thought based on > how PHP passes arguments, it would have been trivial to enhance func_get_args to return an array > indexed not just by numeric values but also string values! > > And therefore one could pass arguments like in python: func(2, 5, $foo => $bar, $baz => > $choo) It also would look exactly like the familiar array composition syntax. But this is no mere > syntactic sugar. It helps developers fall into the pit of success by creating backward-compatible > interfaces and making any function extensible, improving the entire ecosystem. > > Sincerely, > Greg Magarshak > > https://76183cf5.streaklinks.com/ChUGGA0vb2UyLmRu_AoCdl6f/http%3A%2F%2Fqbix.com%2Finvest > > ᐧ > ᐧ > > Third one one: Improve func_get_args to return associative arrays. 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.. Regards Thomas