On 21 November 2025 13:06:30 GMT, Deleu <deleugyn@gmail.com> wrote:
>Here is a very simple hypothetical:
>Suppose I run a website and I have very little understanding of PHP, but I
>know the basics. Every Monday I run composer update, do a little testing
>and deploy the website. Suppose next Monday when I run composer update
>one of my dependencies (Package A) starts to pull in AMPHP as its nested
>dependency. When I try to open my website locally it will either have
>everything broken or it will just work regularly and nothing will be
>running async. There is no other option.
>Now suppose the same example but with PHP 9 + TrueAsync. I do `composer
>update` one day and test my home page and it works. But deeply nested
>somewhere there is a feature that will use Package A which then spawns a
>coroutine and leads to my global state code behaving weirdly. It's not a
>fatal error. It's not very clear at all to me that something changed, but
>now my array indexes are triggering DB updates out of order.
This is basically the exact scenario I had in mind.
For me, having a cast-iron way to avoid this problem is a hard requirement for releasing a version
of PHP with True Async included. Whether that's an ini setting, an annotation that protects
particular parts of the code, etc, is detail we can work out later, but it must be a design
requirement that protecting legacy code in some way is possible.
Debugging tools would be a useful addition, but wouldn't replace the off switch. I know for a
fact that there are applications I will want to run on PHP 9 which will never be worth the
investment to make async-ready. Other applications, I might well run in sync mode initially, then
test and enable async.
And this again highlights why we need a project structure, where we can agree selected details of
the design, with known outstanding issues. I want to be able to say "I approve of the design so
far, with the understanding that X, Y and Z will be addressed before final release".
Regards,
Rowan Tommins
[IMSoP]