Re: PHP True Async RFC
| From: | Rowan Tommins [IMSoP] | Date: | Fri, 07 Mar 2025 23:21:12 +0000 |
| Subject: | Re: PHP True Async RFC | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-126627@lists.php.net to get a copy of this message | ||
On 07/03/2025 22:01, Larry Garfield wrote:
Is that what you're suggesting? If so, I'd have to think it through a bit more to see what guarantees that does[n't] provide. It might work. (I deliberately used spawn instead of "await" to avoid the mental association with JS async/await.) My biggest issue is that this is starting to feel like colored functions, even if partially transparent.Yes, that's pretty much what was in my head. I freely admit I haven't thought through the implications either.
My biggest issue is that this is starting to feel like colored functions, even if partially transparent.I think it's significantly *less* like coloured functions than passing around a nursery object. You could almost take this: async function foo($bar int, $baz string) {
spawn something_else();} spawn foo(42, 'hello'); As sugar for this: function foo($bar int, $baz string, AsyncNursery $__nursery) {
$__nursery->spawn( something_else(...) );} $__nursery->spawn( fn($n) => foo(42, 'hello', $n) ); However you spell it, you've had to change the function's *signature* in order to use async facilities in its *body*. If the body can say "get current nursery", it can be called even if its *immediate* caller has no knowledge of async code, as long as we have some reasonable definition of "current". -- Rowan Tommins [IMSoP]