Re: PHP True Async RFC - Stage 2

From: Date: Fri, 21 Mar 2025 10:50:26 +0000
Subject: Re: PHP True Async RFC - Stage 2
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
>
>  Again, that's the *how*, not the *why*. We only need to "get rid of" the
parentheses if there's some reason to type them in the first place.
>
I’ve already understood that. You mean it’s not the reason, but one of the
possible solutions.
But it’s one of the solutions that, from my point of view, causes less
surprise.
Because the alternatives like spawn fn and spawn {} seem more radical
to me compared to the current design.
In that case, perhaps spawn_fn or spawn closure would be better options..

>
> spawn ( fn() => do_something( fetch_something($input) ) )();

Now this option, I’d say, looks realistic.

> spawn => do_something( fetch_something($input) ) );

Looks good. But then, of course, it turns out that spawn plays two roles —
including defining a closure in the language. That specific point is what
makes me doubt it.
It's like the language has TWO keywords for creating a closure.

Essentially, no matter how you approach it, some compromise will have to be
made.
* Either accept potential confusion between a variable and a function,
* Or agree that a closure will have two forms, and everyone will have to
learn them.

If we go with the second option, then we can use both forms:

```php
spawn use {};
spawn => code;
```

>
>  Again, though, this could easily be added later when a need becomes
> visible, as long as we don't do something weird now that closes the door
> on it.
>

I tend to agree. If there's doubt, it's better to postpone it.

> spawn => $input |> fetch_something(...) |> do_something(...);

It can be made even cleaner by adding a parallelism operator.
That way, there’s no need to write spawn at all.

>
>  I suggest we leave this sub-thread here; there's plenty of other things
to discuss. :)
>

Ok!


Thread (59 messages)

« previous php.internals (#126887) next »