Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126819 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 6BDB61A00BC for ; Tue, 18 Mar 2025 07:26:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1742282646; bh=wrNA91U2hTEZCKgiTJfQuZW6jpCA689sp86RkGhQBHY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ev9GWTUGCaAGYNXZVU/z4BiklFrFUXikzF/TWGt7ARNoHjWg6fI2XhLH6/uInjAEI gG30t601JjscSnxPJhi64/o4lVCRg6ytHVRVF8YT0EFmHSP0Hl956KQ/5KdbD2UkUe 6iCMvR9uQ2axCAdbUDe+VnabTF3E+LdiA48v2wJZh4amPyrTjkggtkjhVyubg5c3gA a+jBIawOmlhEMy2VV6rKCsbjDap/LqNTNYrpTuQDxJWz6q3Vr4HdseE07PSLXbFKfz y3ryw60Kl/kBxtzOrEDCqXOBvurgknttZOgEn10lR8kO9OxpQTnMdjsvu+kz8FySrq 5kOE1bnOAF4Hg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8E6F3180209 for ; Tue, 18 Mar 2025 07:24:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 18 Mar 2025 07:24:05 +0000 (UTC) Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-6f754678c29so58557967b3.0 for ; Tue, 18 Mar 2025 00:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742282796; x=1742887596; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=phdWaDW/1MFJgKTSG50NhHe+Oj6STTyUAUO57hyb7tQ=; b=Hjg81MeV49pPkNckvGZd5hjoRw4XHZfdDGWnWMJUJ3CuW0Of2Jfq5N96rfboLAnBr1 x44wOwU8WWDg47zayP8pehxJFtyMaywAGYzucHAiM+gXDqipFp8txYx8gM3pkJDZy9gP xMxa/uly9c2FswQtciZB+xnXH2sENE14TaTQMrsmYhT7z0PJl15GS2syC0bfhQ/DQwmN v3mh2iyKdKMORzDmvHDByKPRs331nzi6YOwLNQ5Je+06BR8ZRcUV5l/cY3eTkm7ctDg7 qQro3OShurhpT7EiumuXsBFDTHHXEpyVb5wP6o2T2Y/tr6rFJ7Yj56W5vV+MgTCz7p2/ 7Chg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742282796; x=1742887596; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=phdWaDW/1MFJgKTSG50NhHe+Oj6STTyUAUO57hyb7tQ=; b=NaNwi77zNpp7XWFbjJ2DZa7LOPZgieW4FEpRepSwQGphbfrEr8DE3nTD8GWteWipBB +QlXFMhCIUFT5FV+3+Ai9BFX6SvyNtc+dDWCAcmF/mGDYgLiTslslREqBbHl159Emphj DDCeEun9XJnwlbe/ZRW85ExEsWnRuRNA62OHQTBYJDwEyMMBNoVrshhDElCWFrcG7VQs fWzmd4Y+GOiZ5+rauH5dOY5T9dO99bZ7QZZT3OndXQWBDsSasl4+9a7QoPzQMwe9kvqs wism0j62s6VSAPdnJNU8WRratyllZFzW7nInNPcd+avYWaxT8cqYSC6rmH4uWBRbnnW0 2SmA== X-Gm-Message-State: AOJu0YwOt/KszUG6gZmkBHnYTX3/JwlaRUr1Q4RnBq+0OrREZ8mM4W2p PoSKr1Q4w4VjhqgW26pKMR6SMgzx5Dqg7+OlcarCL1hAGydbDC0aX558QmNQvPiKYwy/2QcXQkj 3uUZaPGh+dBDjwHNplFCLgb8v3VA= X-Gm-Gg: ASbGncteQE7iJq6/4glRUiVpNDsG8ItLqKAXmvZpzMe/T8fTOcAMgKs5vf9NoEGxLTM 0BdtyPu+hmRClAm/4m9vV9aYtqxkbPJTPOIidryfHBZT2hMtVgPoT+BFpz1uPxa9uzgYBjGvSCX SbYvQfjjGNKvMgTmCiex8VTsjGtQ== X-Google-Smtp-Source: AGHT+IEUvPcNuUGG//iA4K8hMQ36sUDAS6pe7Ij6Z3FEx4kVu+PBQwcrDag/nrHYNYNLZB8samohQBPd1chVeAXCOEk= X-Received: by 2002:a05:690c:3612:b0:6ff:1fac:c4f2 with SMTP id 00721157ae682-6ff460fa02dmr204226107b3.33.1742282796056; Tue, 18 Mar 2025 00:26:36 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 18 Mar 2025 09:26:24 +0200 X-Gm-Features: AQ5f1JqQXRPLBAqhnDM3On60n9lhqfe19HWcI6WCWr3ctUCVLbBHAOrqEWdjGOA Message-ID: Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2 To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000284cc3063098d3bf" From: edmond.ht@gmail.com (Edmond Dantes) --000000000000284cc3063098d3bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99t really underst= and 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=E2=80=99s 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=E2=80=99s logical that this needs to be mentioned so that those who have= n=E2=80=99t followed the discussion can have the right understanding. What=E2=80=99s 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, *corout= ines 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. --000000000000284cc3063098d3bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, Larry.

>
>=C2=A0<= span style=3D"background-color:rgb(242,242,242);color:rgb(51,51,51);font-fa= mily:"Fira Mono",monospace;font-size:14px">First off, it desperat= ely needs an "executive summary" section up at the top.=C2=A0
= > There'= ;s a *lot* going on, and having a big-picture overview would help a ton. (= For
> ex= amples, see property hooks[1] and pattern matching[2].)=C2=A0=C2=A0<= span style=3D"background-color:rgb(242,242,242);color:rgb(51,51,51);font-fa= mily:"Fira Mono",monospace;font-size:14px">
>
I looked at the examples you provided, but I still don't u= nderstand what exactly I could put in this section.=C2=A0=C2=A0
K= ey usage examples without explanation?
Do you think that would make the RFC better? I don=E2=80=99t really underst= and how.=C2=A0

>
>=C2=A0Second, please include realistic examp= les. Nearly all of the examples are contrived,
>
Wh= ich examples do you consider contrived, and why?=C2=A0=C2=A0

=
>
>=C2=A0The 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. An= d it=E2=80=99s not relevant to the purpose of the example.=C2=A0=C2=A0

>
>=C2=A0And the second is
> built around a code model that I would never,= ever accept into a code base, so it's
> again unhelpful.
>

=
Why?=C2=A0=C2=A0

>
>=C2=A0=C2=A0So would the functions/ke= ywords 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.=C2=A0=C2=A0<= /div>

>
>=C2=A0The first few sections of the RFC seem to read as &qu= ot;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?=C2=A0
Yes, I split this RFC into several parts because it's the only = way to decompose it.=C2=A0
It=E2=80=99s logical that this needs t= o be mentioned so that those who haven=E2=80=99t followed the discussion ca= n have the right understanding.=C2=A0
What=E2=80=99s wrong with t= hat?=C2=A0

>
>=C2=A0=C2=A0Especially the BoundedScope. I see = no reason for it to be separate from just any other
> Scope. What is the differe= nce between scope and context? I have no clue.=C2=A0=C2=A0
>
Agre= ed, this needs to be clarified.

>
>=C2=A0= Are those
<= span style=3D"background-color:rgb(242,242,242);color:rgb(51,51,51);font-fa= mily:"Fira Mono",monospace;font-size:14px">> standard terms yo= u're borrowing from elsewhere, or your own creation?
>=C2=A0=C2=A0

Unfortunately, I couldn't find terminology that de= scribes these models. However, the RFC itself provides definitions. What is= confusing to you?=C2=A0=C2=A0

>
>=C2=A0= =C2=A0I cannot really= tell which one the "playpen" model
> would fit into.
>

If we're talking about the "nursery" model in Pyt= hon, there is no direct analogy because a nursery is not a coroutin= e, but rather a Scope in this RFC.=C2=A0

In= this context, the model in the RFC is essentially no different from nurser= ies 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 stru= ctured concurrency.

In this RFC, there is a nursery (Scope), but in additio= n 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?

>>=C2=A0=C2=A0As = an aside: I used "spawn" as a throw-away keyword to avoid using> "a= wait" 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= 9;t care about it," then it's not suitable. Other neutral alternat= ives could be go or launch or start.
"start" sounds good.

<= div>>
>=C2=A0So any
>=C2=A0proposal should include copious examples of how those three cas= es would look, and why
> they're sufficiently ergonomic.
>

<= div>Thank you, I will add these cases to the examples.

=
>
>=C2=A0
<= /span>>
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 sam= e as creating a global variable using $GLOBAL[].

However, if we're referring to a pattern where a service def= ines its own $scope, then this is probably one of the= most useful aspects of this RFC.

>
>=C2=A0=C2=A0Elsewhere in the thread,= Tim noted that
> we should unify the function call vs closure=C2=A0= question.
>

It would be great if this were possible, but so fa= r, I haven't found a syntax that satisfies both requirements.

Of course, the syntax could be unified like this:

```php

spa= wn function($params): string use() {
}('param');

```

and

```php

function test($x);
spawn test($x);

```

But it looks unnatural...=C2=A0=C2=A0

Right now, I'm m= entally close to the approach that=C2=A0Rowan_Tommins also described.:

<= p>```php

spawn use($parameters): string {};
spawn test($x);
```=

---

Ed.

--000000000000284cc3063098d3bf--