>
> As I write more code examples, I'm starting to get annoyed by the verbosity of the
> spawn in $scope construct—especially in situations where all spawns need to happen
> within the same context.
>
> At the same time, in 80% of cases, it turns out that explicitly defining $scope is
> the only correct approach to avoid shooting yourself in the foot.
> So, it turns out that the spawn in $scope construct is used far more frequently
> than a plain spawn.
>
> with async
>
> ```php
> function generateReport(): void
> {
> try {
>
> $scope = Scope::inherit();
>
> async $scope {
> [$employees, $salaries, $workHours] = await Async\all([
> spawn fetchEmployees(),
> spawn fetchSalaries(),
> spawn fetchWorkHours()
> ]);
>
> foreach ($employees as $id => $employee) {
> $salary = $salaries[$id] ?? 'N/A';
> $hours = $workHours[$id] ?? 'N/A';
> echo "{$employee['name']}: salary = $salary, hours =
> $hours\n";
> }
> }
>
> } catch (Exception $e) {
> echo "Failed to generate report: ", $e->getMessage(), "\n";
> }
> }
>
> ```
>
> #### async syntax
>
> ```php
> async <scope> {
> <codeBlock>
> }
> ```
>
I can see how you think that syntactic sugar is understandably needed for spawn in scope, but again,
you’re still writing code that makes no sense: why do you care about fetchEmployees (a possible
library function) not spawning any fiber?
You already explicitly await all fibers spawned in the generateReport function, you get all the data
you need, any extra spawned fibers should not interest you for the purpose of the logic of
generateReport.
This is because again, the main use case listed of making sure all fibers are done after a request
is a footgun is a non-business-logic requirement, an exercise in functional purity that also reduces
caching and concurrency opportunities, as mentioned before.
A (somewhat bikesheeding, but this has been the vast majority of the posts on this thread anyway)
note is that await could also be made to accept an iterable of futures, avoiding the use of
Async\all combinators.
Regards,
Daniil Gentili.