Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129267 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 lists.php.net (Postfix) with ESMTPS id 5BDE31A00BC for ; Sun, 16 Nov 2025 12:18:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763295490; bh=mJtkLPmfNrlHCYVqdJE51+sCPQAyKXb4KKcywh2J7Oo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cmMBYdVuS4KHn6hF+2bEgbnm+vP7XCnM6aiLujzs2koRAF8P5tsZ+6ccax4nARKkN RF5/AlHN2qQ0h2alX0CnolefPDHSNZnbdBXqrMc3OBWFknrJNLr03y2yALwFyLjllH NjDrcwZKuhdLsxqYiBS09/HUoU77ZOFgc24zkhKXJL93mgN8ppPyYaVqwY45hDBYr7 tVR7wcVJZvILx14SH+5n3DmZZX9KpV3cXL26JCPsHkSkAxivI4xXA6CEFE5wKb8Spd EPE3dJJKyhMKUuSbsAAZrXj311CT1hGfx/bvKzIZ1y47+O9bicdH9OYanaWxrmOddW s65ts2y+DPm1A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0455918066E for ; Sun, 16 Nov 2025 12:18:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,T_SPF_TEMPERROR autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-yx1-f48.google.com (mail-yx1-f48.google.com [74.125.224.48]) (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 ; Sun, 16 Nov 2025 12:17:55 +0000 (UTC) Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-640fc308153so450174d50.1 for ; Sun, 16 Nov 2025 04:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763295470; x=1763900270; 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=mJtkLPmfNrlHCYVqdJE51+sCPQAyKXb4KKcywh2J7Oo=; b=hecvxGMuWLKHSIsQ9mTk+7Nzur2h8as7yzvdwy2troYmxgCxtJZFEbqOig+mEojBJ3 pvkluZEQK0xFLM/j+/yd7T12ldnFnlmntbzm9igW3MJs0rIRhvB0jd/06K7ZPkVNQcHz qIXFIhEXYndQv0CvAeBzCw1+oWBHR+sqXOv8kaNr/G1WjAvr02Dqi9I849Jcf9wUVN/K Uu49eEoTcyB3hHHPhsNxMuHXv7X6DnxBAu2uVSefjPMriVBDy0H5v3/QVByf8NhHremY e2Q1MHCL0yp00DXAEw/EKVYso6gha9QWZR+uB93wSWYbEOIf1fuUmk2+/vnM01hWDs3d bhcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763295470; x=1763900270; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mJtkLPmfNrlHCYVqdJE51+sCPQAyKXb4KKcywh2J7Oo=; b=YxP0auitCjGUJiwa5rCFSQqSd17RbiRWRVORguktXvxukWRPb/GM58LYK1D7NEoJ9k mUyjak5cfzV2t3i0mV0diDg6N4LTuHNxhmldhxHHTiksm5Jm35M2YFQc4vNrBcrbQguY 6dlXdiu4QVGkbKRyiSrRd0HfdHi2qJ+XVhfppf7IrEmn6ZtK+0oy3hHV7UULVcLp9wok 7DJ7uQRNmD+eq5pkHoGgqREwLHs4CHTJt7VGi+Qm6/ghWLiXxPP39HkrOnOtcfgnpwhJ y6zxdv5En6tIVlwuslyMN6Uebvod7hSKSEozJzXh4wa25nL8GuOD85VqNFHlr2I9hKPx 9EMg== X-Forwarded-Encrypted: i=1; AJvYcCWpfQpMgrT8Ens4UNfASoTyaxkX7ie7kfqZ9+1Y3LYyCQKCNSnaMOAJQI7AEd2ApSs6vgXVgLjTgUw=@lists.php.net X-Gm-Message-State: AOJu0Ywp9n/Y8tHUHwRVwrng4Ljd+49uFBGgXa7bLS4d1GB4cT4v3HPF 2c9WafyoT9FQxPaBzb6GxtLojQKAwbH9ynqGilwvdfAFx+4Rc8mXbg39j1zuLn+ExcqScMG8InF RMiCrf4B4beTpBu71isE14ChXiqHP4hE= X-Gm-Gg: ASbGnct10ry9LXMWn3ICNQltpsLEBMJS3xYZPhYnRvxzLwO7M59b4WK3UDXx7mF8hdh MGBWOapqTzHutdU8TBFRap33/V/g5H/b0Pzy9LZ+9hccONxf6qh5cMkKkPOPmLAe5MaumTbO2EY P6Q6bBsY9yd9C3MGy/BJRRsWVEGfyWTfKbgiXRI/jWcrc2C+enaM8AcMWcQ2WIS0/Cjm70DS4nk 4QFVlSLOurjeBifMct4l2aZtDCXrz0w/wb6PSsAGDxYRv7ESFhQ34qzJSSpqs4orhxMcyockO1I cdNwwqjL+0rOuLUOvJMouIIMbkcu+02h/ahJVg== X-Google-Smtp-Source: AGHT+IHSUzdgvgYgCQ0FqP/xuTmVdKAZHxDj4UTaT/83b/WL2HyIU/EIug/ZWqIet5aOd3PmAglx/TXTBuGbD90U/Xc= X-Received: by 2002:a05:690c:6d84:b0:788:16d7:6ebb with SMTP id 00721157ae682-7892ac54ea7mr54724167b3.5.1763295469930; Sun, 16 Nov 2025 04:17:49 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> <3e0cf0a1-c1a3-4e05-97ba-0eeb7f559a53@app.fastmail.com> In-Reply-To: Date: Sun, 16 Nov 2025 09:16:54 -0300 X-Gm-Features: AWmQ_blSeVfTEJfjhAxG6OQH1_4-OcwfaE7TWCnSv3kEzNlnWBHUA8MMY82Tsbg Message-ID: Subject: Re: A Thank you (was Re: [PHP-DEV] PHP True Async RFC Stage 5) To: Edmond Dantes Cc: Michael Morris , php internals Content-Type: multipart/alternative; boundary="0000000000001e8e980643b538f7" From: deleugyn@gmail.com (Deleu) --0000000000001e8e980643b538f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This thread is a clear, explicit and direct representation that there are people following all the hard work that you=E2=80=99ve put into this RFC. I= dare say that nobody doubts your intentions, effort and initiative to tackle such a complex and hard task. The next step is to recognize that anybody participating in an RFC discussion is a person taking time out of their lives, their family, their work, their hobbies and volunteering their time similar to you. Everyone has PHP best interest at heart even if what we think is best for PHP differs. On Sun, 16 Nov 2025 at 03:56 Edmond Dantes wrote: > Hello > > > Maybe that=E2=80=99s inherent to a subject matter that indeed could be = the > biggest change to PHP since 7, > > but given RFC voting history, all signs point to a rejection vote. > > I think so too. > > > I don=E2=80=99t know how much has been discussed off list and/or how ma= ny voters > are involved off list. > > There were almost no discussions apart from the one on INTERNALS. I > mean, there were no discussions that I=E2=80=99m aware of. > > I don=E2=80=99t know what to do about a situation where PHP developers ar= e > surprised to learn that their language has supported transparent > asynchrony as a core paradigm for several years already. I suppose you=E2=80=99re referring to Swoole, AMPHP, ReactPHP, etc. While t= here=E2=80=99s no denying they=E2=80=99re an important part of the ecosystem and living pr= oof there=E2=80=99s room for asynchronous PHP, your positioning here seems to a= ssume that everybody participating in your RFC should know, understand and use one of these projects and have that baseline knowledge. From my personal experience, context and little bubble, I would guess that less than 10% of PHP engineers worldwide has any firsthand experience with any of these tools combined. Your RFC can bridge that gap, but to do so you need to be able to address why the other 90% hasn=E2=80=99t used any of these existing approaches. Your target audience is exactly the opposite of what you expect= . > And instead of discussing the important details of the RFC, all the > effort goes into =E2=80=9Cbasic questions=E2=80=9D that aren=E2=80=99t wo= rth discussing at > all. This is perhaps the most likely reason for the RFC to fail a vote. Let=E2= =80=99s break down voting in an abstract format. Some common reasons voters may choose to vote NO are: - they don=E2=80=99t like the change and don=E2=80=99t want it on PHP - they disagree with the approach - the change increases PHP maintenance burden for a subjective benefit - the RFC is unclear There=E2=80=99s not much you can do about 1. And for every NO you get, you = need 2 YES to overcome it. My personal guess is that 4 would drive a lot of NO and the reason is a combination of factors. It=E2=80=99s a very complex and dense RFC and not e= very voter will have any experience with the existing async tools provided by the community. When trying to take time out of their personal lives to go through such a complex and extensive RFC, basic questions will arise. They will attempt to address it before going deeper and deeper and will be met with a dismissive response from the author =E2=80=9Cbecause this is too bas= ic and we shouldn=E2=80=99t focus on it=E2=80=9D. They will make the easy choice t= o not continue to volunteer their time into something so hard to wrap your head around since it=E2=80=99s too challenging to even get past the basics. A negative = result is not really a surprise at this point. It would be wonderful if there were a dedicated person whom everyone > would listen to carefully and who could explain the basic questions > privately. Most likely, this approach would solve many problems. > > --- > Best Regards, Ed Short of forking PHP, that seems like wishful thinking. PHP is driven by committee and there doesn=E2=80=99t seem to be any way around that. But the= re are approaches you can try. One of them is pairing it up with someone better at docs, communication, etc. Take a look at Larry=E2=80=99s RFCs. Majority of it he doesn=E2=80=99t= write any C code, but he makes up for it 10 times by producing clearly readable, understandable and decision points communicated. Voters may still disagree at the end, but it always feels like they understand what they=E2=80=99re v= oting on/for. I don=E2=80=99t know if you=E2=80=99re good with a camera, but going in a p= odcast with someone like Brandt, Nuno Maduro or any other PHP podcast that tries to breakdown internals for easy consumption could also help your cause. Ultimately, I think your vast expertise on the matter is both a blessing and a curse. A blessing because without it maybe the RFC would have never even existed - at least no other RFC on the matter has reached so far. A curse because nobody else seems to be able to understand what you=E2=80=99r= e saying, what you=E2=80=99re doing and what PHP will be like if your RFC is = approved. As someone writing PHP for 15 years, I=E2=80=99m scared of bringing any asy= nc community tools to any project I work because I don=E2=80=99t know what wou= ld break. Your RFC states that you want all my code to keep working which is great, but the moment I make use of something async it could inadvertently affect something and I don=E2=80=99t know what/why/how. I=E2=80=99m dumb an= d don=E2=80=99t know how async works and I don=E2=80=99t want PHP to allow me to shoot myself in the= head like that. Is there anything you can do about it? I wish you all the best luck on the RFC and your next steps. I thank you for all your time so far and I=E2=80=99m eager to see what come out of it. > --0000000000001e8e980643b538f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This thread i= s a clear, explicit and direct representation that there are people followi= ng all the hard work that you=E2=80=99ve put into this RFC. I dare say that= nobody doubts your intentions,=C2=A0effort and initiative to tackle such a= complex and hard task.

The next step is to recognize tha= t anybody participating in an RFC discussion is a person taking time out of= their lives, their family, their work, their hobbies and volunteering thei= r time similar to you. Everyone has PHP best interest at heart even if what= we think is best for PHP differs.=C2=A0

On Sun, 16 Nov 2025 at 03:56 Edmond Dantes <= ;edmond.ht@gmail.com> wrote:<= br>
Hello

> Maybe that=E2=80=99s inherent to a subject matter that indeed could be= the biggest change to PHP since 7,
> but given RFC voting history, all signs point to a rejection vote.

I think so too.

> I don=E2=80=99t know how much has been discussed off list and/or how m= any voters are involved off list.

There were almost no discussions apart from the one on INTERNALS. I
mean, there were no discussions that I=E2=80=99m aware of.

I don=E2=80=99t know what to do about a situation where PHP developers are<= br> surprised to learn that their language has supported transparent
asynchrony as a core paradigm for several years already.

I suppose you=E2=80=99re referring = to Swoole, AMPHP, ReactPHP, etc. While there=E2=80=99s no denying they=E2= =80=99re an important part of the ecosystem and living proof there=E2=80=99= s room for asynchronous PHP, your positioning here seems to assume that eve= rybody participating in your RFC=C2=A0should know, understand and use one o= f these projects and have that baseline knowledge. From my personal experie= nce, context and little bubble, I would guess that less than 10% of PHP eng= ineers worldwide has any firsthand experience with any of these tools combi= ned. Your RFC can bridge that gap, but to do so you need to be able to addr= ess why the other 90% hasn=E2=80=99t used any of these existing approaches.= Your target audience is exactly the opposite of what you expect.


And instead of discussing the important details of the RFC, all the
effort goes into =E2=80=9Cbasic questions=E2=80=9D that aren=E2=80=99t wort= h discussing at
all.


This is perhaps the most likely reason for the RFC to fail = a vote. Let=E2=80=99s break down voting in an abstract format. Some common = reasons voters may choose to vote NO are:

=
- they don=E2=80=99t like the change and don=E2=80=99t wa= nt it on PHP
- they disagree with the approach
=
- the change increases PHP maintenance burden for a subje= ctive benefit
- the RFC is unclear

There=E2=80=99s not much you can do about= 1. And for every NO you get, you need 2 YES to overcome it.

My personal guess is that 4 would dri= ve a lot of NO and the reason is a combination of factors. It=E2=80=99s a v= ery complex and dense RFC and not every voter will have any experience with= the existing async tools provided by the community. When trying to take ti= me out of their personal lives to go through such a complex and extensive R= FC, basic questions will arise. They will attempt to address it before goin= g deeper and deeper and will be met with a dismissive response from the aut= hor =E2=80=9Cbecause this is too basic and we shouldn=E2=80=99t focus on it= =E2=80=9D. They will make the easy choice to not continue to volunteer thei= r time into something so hard to wrap your head around since it=E2=80=99s t= oo challenging to even get past the basics. A negative result is not really= a surprise at this point.

It would be wonderful if there were a dedicated person whom = everyone
would listen to carefully and who could explain the basic questions
privately. Most likely, this approach would solve many problems.

---
Best Regards, Ed

= Short of forking PHP, that seems like wishful thinking. PHP is driven by co= mmittee and there doesn=E2=80=99t seem to be any way around that. But there= are approaches you can try.=C2=A0

One of them is pairing it up with someone better at docs, commun= ication, etc. Take a look at Larry=E2=80=99s RFCs. Majority of it he doesn= =E2=80=99t write any C code, but he makes up for it 10 times by producing c= learly readable, understandable and decision points communicated. Voters ma= y still disagree at the end, but it always feels like they understand what = they=E2=80=99re voting on/for.=C2=A0

I don=E2=80=99t know if you=E2=80=99re good with a camera, but= going in a podcast with someone like Brandt, Nuno Maduro or any other PHP = podcast that tries to breakdown internals for easy consumption could also h= elp your cause.

Ultimate= ly, I think your vast expertise on the matter is both a blessing and a curs= e. A blessing because without it maybe the RFC would have never even existe= d - at least no other RFC on the matter has reached so far. A curse because= nobody else seems to be able to understand what you=E2=80=99re saying, wha= t you=E2=80=99re doing and what PHP will be like if your RFC is approved.

As someone writing PHP fo= r 15 years, I=E2=80=99m scared of bringing any async community tools to any= project I work because I don=E2=80=99t know what would break. Your RFC sta= tes that you want all my code to keep working which is great, but the momen= t I make use of something async it could inadvertently affect something and= I don=E2=80=99t know what/why/how. I=E2=80=99m dumb and don=E2=80=99t know= how async works and I don=E2=80=99t want PHP to allow me to shoot myself i= n the head like that. Is there anything you can do about it?

I wish you all the best luck on the R= FC and your next steps. I thank you for all your time so far and I=E2=80=99= m eager to see what come out of it.
--0000000000001e8e980643b538f7--