Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126821 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 4C1231A00BC for ; Tue, 18 Mar 2025 08:22:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1742286001; bh=4+eXIiKhdKo+g5RtDvASdRQtyguKd+8Dm8+J7TMOYmY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lx7/1wdaTmC9m2hbfjypVcAh0Ky/MSLIEEYydz9um9/HeWhl9M/XwooDVEZKJ8FBl 9e9UPRep6eHkfDdN6qJ/8f3bKg6V54S98w6Ba0sccTf+o/BKuqwd/WAIe5oHyxosH/ Tc79JIz+Qs3c3rV4RRwAD1Ls6uc/TC9eTTe49RZOK1I1b2eEYQGxnX8JG/m+/ykbgw j79uu22s1GRRuoUttvknO/4LJ8oZ98PohMbUJ6eqO/k5vuh+t8lvHAKpbX9WfHh2jg 7HnZmc6T7p9byoW3kLXNzZZ6gtsfUEO5KwWPNeJbXkJj60drrSKPE4ekdI3D+utTMq 4+BV2jmmx/QGg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8CE451804B4 for ; Tue, 18 Mar 2025 08:20:00 +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=-2.0 required=5.0 tests=BAYES_40,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-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (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 08:20:00 +0000 (UTC) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-e637669ef11so4196639276.1 for ; Tue, 18 Mar 2025 01:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742286151; x=1742890951; 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=rTpRFjg8qM6uyuNGvKJC7YVAgFiLviJ8h388XLmqyVU=; b=VVC7twrd0jUUegIYVdddyd6cv1cUbZ9g4DzjKi8uy/i+LGBp//Cypp8faoX2SiOpT2 PHhW4SVIL0DQFurzfswk/zAJCmiA+TmcwW/K2lGtqoCTOoBlwfgHMprv6qvzDFdIXPZE dOWlNMzapshSgTWsFSFfuwBHzW5ZAKnC7Pmnz9lpJl4vGGnsrQLpkfIqMGhtUu5e0AeZ WwQFEdw5y9T0Htw2W7462hH/tmK69QOJF8toguBLuBsCvZv5M6CIt9LhnrFJ4e/RrKu7 HaZqvDhK0fCrcgNmO8N1a/IH/t8zPe5FvCn2eswlecGn+G5ur1ExyoHlICwsjTib/VZf c2Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742286151; x=1742890951; 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=rTpRFjg8qM6uyuNGvKJC7YVAgFiLviJ8h388XLmqyVU=; b=Mh8HgnlpqsLGDrLkehPa0fI/c0RqkePtaYXCG+GKqM0A98sjZ7gMlSAg07+r9MCsfi 6jJ/EZ6nfCHXGs0HNM01Z/nDYfZnYR0tvdiNgOh96gPbdxD4kDhOFMKA1L+9rNT2PIRX qu0qGEvoyZY1KdQHvKI+bcfBc1yiBImHZaVyifXpL5ZfHURkyRpmQ+cWde/j/uoxrct6 S16dJBQOTO0pukVffRZfe4EqkLLMceLDjjkeTAVlKXd9+ztP+D6wC3DVIniMD/n+r8ME uAaSsg6uSObt5oDv1WRUVNXPwCk9MtsbNEz+PCEzEKjshlukqxwgNM71527yzuCwp2g5 eS8A== X-Gm-Message-State: AOJu0YzXSpLAJlBXEF+eK/pRXb0rrNxjUCYLGEvhcgmqOY3b8gCfxqUo 08U2L6G75sSaLcu0HUzpRSF1g26/hryh4Hwmwec7jozQX0mBSwYC0DSCzmZioSMwhCc/i1C60NI 7hp4JlBSl1LL4h9mnmEBP2uaZF1I= X-Gm-Gg: ASbGncuUBTQZX7TMNii7ZaWHugfUeX+5+o+L+6kwKLrCgLIT02IwqcjUQyao778SK+f kthPqwb0FLM5o1xmXhwAAsU3fGM8qVGLFGX5fXgoUkXmVXNwMgZB6awUrtc6mooubICtTbYml1X MMzDYnmDPMc20u3sYC7CGPactpnIgukbH/LYve X-Google-Smtp-Source: AGHT+IHhiIaXMEOfxSLVdE+d7lKdW7p0yedtYt2aw25SJU1zG2guJw+Qc/z86dJgTX0zbjNBSNM82+SJ+lQy4vCumtA= X-Received: by 2002:a05:6902:1ac2:b0:e63:d10e:edc4 with SMTP id 3f1490d57ef6-e64af0eb44dmr3847283276.10.1742286151088; Tue, 18 Mar 2025 01:22:31 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <72bd5401-53a9-409f-ad45-687333401961@rwec.co.uk> In-Reply-To: Date: Tue, 18 Mar 2025 10:22:18 +0200 X-Gm-Features: AQ5f1JoqJiLji0Jkoa1qILAN8QK1gku6EowW2bhmC0LMjH9aGSC591pPW8ROliE Message-ID: Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2 To: "Rowan Tommins [IMSoP]" Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000220c700630999b5d" From: edmond.ht@gmail.com (Edmond Dantes) --000000000000220c700630999b5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > spawning in a scope a "second-class citizen" if `spawn foo($bar);` > Reminds me of *"post-purchase rationalization"* or the *"IKEA effect".* when effort has already been invested into something, and then suddenly, there's a more convenient way. And that convenient way seems to devalue the first one. But it looks like the `$scope->spawn` syntax really does have an advantage over `spawn in $scope`. So what do we do? Avoid using what's convenient in pursuit of perfection? > I did say the names were subject to bikeshedding Yes, I don't disagree that a keyword would be very useful, even outside the context of coroutines. And again, there's the question of whether it should be introduced directly in this RFC or if it would be better to create a separate one. > > I'm confused - $scope->onExit() is already in the RFC, and I wasn't suggesting any change other than the syntax. > (Although I'm not sure if it should defer to coroutine exit rather than scope exit by default?) > Yes, that's correct. The onExit method can be used for both a coroutine and a Scope. As for the method name onExit, it seems like it would be better to replace it with something clearer. > > spawn foo(42); > // spawns a call to foo with argument 42 > I like it. > > spawn call bar(...); > It doesn't make sense because the arguments must be defined. By the way, I looked at the definitions in the Bison file this morning, and in principle, there's no problem with doing this: ```php spawn use(): returnType {}; ``` > Is this just a description of your own comprehension, or based on some more general experience of something similar? Yes, it's more of a mental model. > > Is there a reason to redefine all of this and make fresh decisions about what to allow? > If we strictly follow syntax consistency, then of course, we need to cover all possible use cases. But when I see code like this: ```php spawn ($this->getSome()->getFunction())($parameter1, ...); ``` I start seeing circles before my eyes. =F0=9F=98=85 Okay, if we're going that route, then at least something like this: ```php spawn $this->getSome()->getFunction() with ($parameter1, ...); ``` So the syntax would be: ``` spawn [with ()]; ``` So... ```php spawn test with ("string"); spawn test(...) with ("string"); spawn test(...); // without args spawn function(string $string) use() { } with ("string"); ``` These examples look better in terms of consistency, but they are no less surprising. --- Ed. --000000000000220c700630999b5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>
>=C2=A0 spawning in a s= cope a "second-class citizen" if `spawn foo($bar);`
>= ;

Reminds me of "post-purchase rationali= zation" or the "IKEA effect".

<= p>when effort has already been invested into something, and then suddenly, = there's a more convenient way. And that convenient way seems to devalue= the first one.

But it looks like the `$scope->spawn` syntax really does= have an advantage over `spawn in $scope`.

So what do we do? Avoid using what's convenient in pursuit of perfec= tion?

>=C2=A0I did say the names were subject to bikeshedding

Ye= s, I don't disagree that a keyword would be very useful, even outside t= he context of coroutines. And again, there's the question of whether it= should be introduced directly in this RFC or if it would be better to crea= te a separate one.=C2=A0=C2=A0

>
>=C2=A0 I'm confuse= d - $scope->onExit() is already in the RFC, and I wasn't suggesting = any change other than the syntax.
> (Although I'm not sure if it= should defer to coroutine exit rather than scope exit by default?)<= br>>

Yes, that's correct. The onExit method can b= e used for both a coroutine and a Scope.
As for the method name onExit, it seems like it would be bette= r to replace it with something clearer.=C2=A0=C2=A0

>
>=C2= =A0 spawn foo(42);<= /span>
> // spawns a call to f= oo with argument 42
>

I like it.

>
>=C2= =A0 spawn call bar(= ...);
>

It doesn't make sense because the arguments = must be defined.

By the way, I looked at the definitions in the Bison file this morni= ng, and in principle, there's no problem with doing this:

```php<= /p>

spawn use(): returnType {};

```

>=C2=A0Is this just a description= of your own comprehension, or based on some more general experience of som= ething similar?

Yes, it's more of a mental model.=C2=A0=C2= =A0

<= p>>
>=C2=A0 Is there a reas= on to redefine all of this and make fresh decisions about what to allow?
>

If we strictly follow syntax consistency, then of course= , we need to cover all possible use cases.

But when I see code like this:

```php

spawn ($this->g= etSome()->getFunction())($parameter1, ...);

```

I start = seeing circles before my eyes. =F0=9F=98=85

Okay, if we're going that route, then at least something like th= is:

```php
spawn $this->getSome()->getFunction() with ($para= meter1, ...);

```

So the syntax would be:=C2=A0=C2=A0

```

spawn <exp> [with (<args>)];

```

So.= ..

```php

spawn test with ("string");
spawn test(.= ..) with ("string");
spawn test(...); // without args
spawn= function(string $string) use() {
} with ("string");

```

These examples look better in terms of consistency, but they are= no less surprising.

---

Ed.

--000000000000220c700630999b5d--