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
ᐧ
ᐧ
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
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
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+php@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
Hi everyone. Just wanted to follow up on this. Is there any chance of
switch_global_context making it into PHP 9? This would be a huge
game-changer as e.g. FrankenPHP in worker mode could literally be up to
100x faster than PHP-FPM! But right now, most frameworks which benefit from
the awesome shared-nothing architecture (using static Foo::$bar,
superglobals, PDO, etc.) are stuck, and need a complete rewrite. With this,
they wouldn't.
I understand that switch_global_context() might have a bit of trouble with
database pools or whatnot (since some connections wouldn't be released) and
therefore would actually end up making a process block until the
connections are available. This may be tricky. But the goal of porting all
existing PHP code to take advantage of worker mode is extremely worth it,
even if some threads end up blocked temporarily it's still strictly faster
and better than PHP-FPM and FrankenPHP classic mode.
Sincerely,
Greg Magarshak
https://76183cf5.streaklinks.com/CkyAlxNdnd52rqGCJwHgpr1X/http%3A%2F%2Fqbix.com%2Finvest
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/l9r8UJP6RkThere 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 Magarshakhttps://76183cf5.streaklinks.com/ChUGGA0vb2UyLmRu_AoCdl6f/http%3A%2F%2Fqbix.com%2Finvest
ᐧ
ᐧ
ᐧ
Hi everyone. Just wanted to follow up on this. Is there any chance of
switch_global_context making it into PHP 9? This would be a huge
game-changer as e.g. FrankenPHP in worker mode could literally be up
to 100x faster than PHP-FPM! But right now, most frameworks which
benefit from the awesome shared-nothing architecture (using static
Foo::$bar, superglobals, PDO, etc.) are stuck, and need a complete
rewrite. With this, they wouldn't.
Hi Gregory,
Something that's not necessarily obvious to new contributors is that the
PHP project has no central organising committee, and no permanent core
team. We now have the PHP Foundation to provide some stable funding
(persuading companies to sponsor that is a great way to help the
project!), but there's no official roadmap or backlog we can add ideas to.
What that means is that while new ideas are welcome, they're not
necessarily going to get an immediate "yes" or "no". (It also means that
everything in this e-mail is just the personal view of a long-term but
minor contributor, and not any kind of official policy.)
Broadly, you need to start from one of these two points:
a) I've got an idea, and the necessary skills to implement it, but
before I spend any more time on it I want to know if it's likely to be
accepted by the Internals community
b) I've got an idea, but don't have the necessary skills to implement
it, would anyone be interested in working on it with me?
If nobody responds at all to an idea, it probably means that nobody
really hates the idea, or can see a reason why it's impossible; but
nobody is that excited by it either. If you're interested, you need to
develop the idea further, and make clear if you're volunteering to
implement it, or looking for a partner to implement it with you.
In this case, I'm not really clear what the proposal is, or how it would
work. When exactly would the switch_global_context() function be called,
and who would choose a value for $name? What kinds of state would it
"switch", and how would that be different from switching between
separate shared-nothing threads or child processes? Surely some (all?)
of the speed-up of an event-based run-time is carrying state from one
request to another.
I am definitely not an expert, but I also suspect it would be a lot
more complex than you imply - there's a lot of different memory
allocations and pointers involved in the PHP runtime, and even making
them thread-safe involves a lot of complexity in the current implementation.
P.S. The rule here is to type your reply below the quoted text it's
referring to, trimming as appropriate, as I've done here.
--
Rowan Tommins
[IMSoP]