Here are list of the problems i saw in this RFC:

1.) The `spawn` keyword might disqualify this rfc, i talked to alot of php
devs about this rfc and they all had a similar complaint about the keyword,
maybe a keyword choice poll might help when the rfc voting goes live.

2.) This whole rfc seem a little bit complex, which might ruin php codebase
readability, let's keep things simple and concise, first impression matters
for beginners and intermediate php programmers.

3.) Let's not derive impression from java at this point, PHP might look
similar to java but programmers hate java for a reason, overbloated way of
doing simple things.



On Thu, 17 Apr 2025, 9:55 am Edmond Dantes, <edmond...@gmail.com> wrote:

> Hello, Rowan!
>
> > I don't have time to dig into the details of this draft at the moment,
> but will say that a vote in two weeks is not at all realistic.
> I just used the Flow from the Wiki. :)
>
> > My only other comment at a very quick glance is that I see the Context
> section is still included, and still has most of its complexity.
> Almost every section of the RFC has a "Motivation" subsection, which
> explains why a particular tool is needed and what problem it solves.
> I removed everything from the RFC that is not directly related to
> asynchrony or not essential at this stage.
>
> Yesterday I also received feedback that the RFC contains too many changes,
> so I can briefly summarize what’s new in this version compared to the
> previous one:
>
>    1.
>
>    The Scope class can no longer be used in an await expression. A
>    separate method is now provided for waiting on a Scope, intended only for
>    special use cases.
>    2.
>
>    Scope is now responsible solely for coroutine lifetime and error
>    handling.
>    3.
>
>    A TaskGroup class has been added for working with groups of tasks. It
>    is used explicitly with the expression spawn with $taskGroup. Together
>    with Scope, TaskGroup supports structured concurrency, offering
>    different strategies for tracking hanging coroutines.
>
> *These are the key changes.*
>
> *Secondary changes include:*
>
>    1.
>
>    Syntax refinement
>    2.
>
>    Edge case handling
>    3.
>
>    Ability to extend spawn with logic
>    4.
>
>    Added combinator functions: all, any, anyOf, ignoreErrors
>    5.
>
>    A special function Async\protect() has been added for critical
>    sections that cannot be cancelled.
>    6.
>
>    Improved examples
>
> Contextual expressions like with $context and async blocks were removed
> from the RFC as they are out of its scope.
>
> The next important step is to determine which coroutine model to choose.
> There are three models in total:
>
>    1.
>
>    Go – no Scope
>    2.
>
>    Java Loom – Scope is always passed explicitly
>    3.
>
>    The current RFC – Scope is passed both explicitly and implicitly
>
> The choice of model affects both the syntax and the API. Therefore, if the
> current model is not accepted, there is no point in further developing this
> RFC — a new one should be created instead.
>
> This is the key question I want to clarify at this stage.
>
> --
>
> Ed
>

Reply via email to