Hi, I have now read more thoroughly through the whole RFC, and I am less happier with it than I was.
On Tue, 14 Oct 2025, Edmond Dantes wrote: > On Tue, 14 Oct 20205, Larry Garfield wrote: > > > It's vastly improved from the first version back in the spring, but > > there are still numerous footguns > > Which specific footguns? $scope var? There are many as I see them, to name a few: - A new ini setting — we would be much better off picking a value, and stick with with it. - Showing warnings when all sort of issues happen. - Indeed, the passing around of "$scope". - "A good practice is to ensure that a Scope object has only ONE owner." — that really ought to be enforced - "Passing $scope as a parameter to other functions or assigning it to multiple objects is a potentially dangerous operation that can lead to complex bugs." — so this isn't something a design should even allow. - "Awaiting a Scope is a potentially dangerous operation that should be performed consciously, not accidentally. " — a design should prevent PHP users from making potentially dangerous situations. - Disposing etc, I don't think I even understand what you're trying to do with this, considering warnings, zombies, etc. - "Warning: You should not attempt to suppress CancellationError exception, as it may cause application malfunctions." — again, a good design should not require our users to have to think of this. - Hierarchies of scopes make for a lot of complexity. I doubt whether this is useful in most cases. There is a lot of complexity and I still also think this RFC is trying to do way too much. PHP is *primarily* used as a web language, and the goal of adding concurrency into it should make the live of web developers easier. This seems to be designed fo running PHP as a long time running script/event loop. We have web servers and FrankenPHP for that. In addition: The RFC also doesn't describe how scheduling works. You call it "out of scope", but as this is needed for this whole concept to work, it very much ought to be in scope. In the second example of "Coroutine::onFinally" there is an onFinally() call without object. Under "Tools", there is: "getSuspendFileAndLine():array Returns an array of two elements: the file name and the line number where the coroutine was last suspended. If the coroutine has not been suspended, it may return empty string,0." Returning bogus values (empty string, and 0) isn't a good idea. Instead, the method should probably have a "?array" return type. "The format of this array depends on the implementation of the Scheduler and the Reactor." — Spell out what these are, and how they're supposed to work. We cannot make decisions on non-complete information. "Therefore, using concurrency is reasonable only for long-life scenarios implemented via CLI." — I thought the whole point of this was so that developers can use concurrent things during their *web* requests — for example running several queries at the same time, or doing multiple http requests. Isn't that what you would expect people to use concurrency for? I don't understand why the "NGINX Unit integration example" is part of this RFC. > > I very much want to see it evolve further in that direction before a vote > > is called and we're locked into a system with so many foot guns built in. > > Such an approach would require more changes to the code, and I don’t > see how it would protect the programmer from mistakes any better than > this RFC does. In my opinion, it was not wise to spend so much time on the code (beyond prototyping). The role of the RFC process is to hammer out a good feature for PHP, with the code being (mostly) an implementation detail. > My position is this: **TrueAsync** should support the best patterns > for specific use cases while still remaining convenient for the > majority of tasks. The "Goals" describe what you would like this feature to be, but not *why*. The RFC does not describe why this feature is important for PHP for specific use cases at all. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @[email protected] @[email protected]
