Hello, Larry.
>
> First off, it desperately needs an "executive summary" section up at the
top.
> There's a *lot* going on, and having a big-picture overview would help a
ton. (For
> examples, see property hooks[1] and pattern matching[2].)
>
I looked at the examples you provided, but I still don't understand what
exactly I could put in this section.
Key usage examples without explanation?
Do you think that would make the RFC better? I don’t really understand how.
>
> Second, please include realistic examples. Nearly all of the examples are
contrived,
>
Which examples do you consider contrived, and why?
>
> The first non-foobar example includes a comment "of course you should
> never do it like this", which makes the example rather useless
>
Do you mean working with a closure that captures a reference to $this?
But that has nothing to do with this RFC, either directly or indirectly.
And it’s not relevant to the purpose of the example.
>
> And the second is
> built around a code model that I would never, ever accept into a code
base, so it's
> again unhelpful.
>
Why?
>
> So would the functions/keywords be shortcuts for
> some of the common functionality of a Scope object?
>
Were you confused by the fact that the Scope object has a spawn method?
(Which is semantically close to the operator?)
I understand that having both a method and an operator can create
ambiguity, but it's quite surprising that it could be so confusing.
>
> The first few sections of the RFC seem to read as "this RFC doesn't
actually
> work at all, until some future RFC handles this other part."
>
How should I have written about this? It's simply a part of reality as it
is. Why did this cause confusion?
Yes, I split this RFC into several parts because it's the only way to
decompose it.
It’s logical that this needs to be mentioned so that those who haven’t
followed the discussion can have the right understanding.
What’s wrong with that?
>
> Especially the BoundedScope. I see no reason for it to be separate from
just any other
> Scope. What is the difference between scope and context? I have no clue.
>
Agreed, this needs to be clarified.
>
> Are those
> standard terms you're borrowing from elsewhere, or your own creation?
>
Unfortunately, I couldn't find terminology that describes these models.
However, the RFC itself provides definitions. What is confusing to you?
>
> I cannot really tell which one the "playpen" model
> would fit into.
>
If we're talking about the "nursery" model in Python, there is no direct
analogy because a *nursery is not a coroutine*, but rather a *Scope* in
this RFC.
In this context, the model in the RFC is essentially no different from
nurseries in Python.
The key difference lies elsewhere.
To define the structure, two elements are used:
- The coroutine itself
- An object of type *Nursery* or *Scope*
So in Python, coroutines work exactly the same way as in Go, and the
*nursery* is an additional mechanism to ensure structured concurrency.
In this RFC, there is a *nursery (Scope)*, but in addition to that, *coroutines
themselves are also part of the structure*.
(So this RFC uses a stricter approach than Python)
Does this mean it's not clear from the text?
>
> As an aside: I used "spawn" as a throw-away keyword to avoid using
> "await" in a previous example. It's probably not the right word to use in
> most of these cases.
>
If the verb *spawn* implies that "the code throws something overboard and
doesn't care about it," then it's not suitable. Other neutral alternatives
could be *go* or *launch or start.*
"start" sounds good.
>
> So any
> proposal should include copious examples of how those three cases would
look, and why
> they're sufficiently ergonomic.
>
Thank you, I will add these cases to the examples.
>
> I honestly cannot see a use case at this point for starting coroutines in
arbitrary scopes.
>
If we're talking about launching a coroutine in *GlobalScope*, then it's
99% likely to be an *anti-pattern*, and it might be worth removing
entirely. It's the same as creating a global variable using $GLOBAL[].
However, if we're referring to a *pattern where a service defines its own
$scope*, then this is probably one of the most useful aspects of this RFC.
>
> Elsewhere in the thread, Tim noted that
> we should unify the function call vs closure question.
>
It would be great if this were possible, but so far, I haven't found a
syntax that satisfies both requirements.
Of course, the syntax could be unified like this:
```php
spawn function($params): string use() {
}('param');
```
and
```php
function test($x);
spawn test($x);
```
But it looks unnatural...
Right now, I'm mentally close to the approach that Rowan_Tommins also
described.:
```php
spawn use($parameters): string {};
spawn test($x);
```
---
Ed.
