> Gregory Magarshak <g...@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
