Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129831 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 A3D121A00BD for ; Wed, 21 Jan 2026 21:54:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1769032464; bh=4IlGVf2hRwQ6sRa9HuEyMkbJ9Y3vS2icd83i6C2DeZk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mNNlkP+M1qsOXkV315f4t3oLBkrgUuPuvb071h4gyFvZ+/oiEmrYlNE1GEqB6WSLS +dfU7VIcbRJClikL3KiFKC/omCuveSR7W2t76e4PjjvxNinxv6MkJ3lksyKrOR7WLw 7M64AgD76gCaZCaYPrgdIaKGPRKuE0rXZGucNme82cAKHKJ0lAmnkmYn9tqYDT1QMj MuD93a+I170gXH2Ua8KXCiawsQiXdg9dO2ahLaoEllpL8Yk2+nmHgCsRhpea7YUA1l JSA9QMaQ7YtO80UQePFvcFO+SwKU4ZiMS0FVekfIQwLlky3EGTwTNmsZ692dk2FQXr Iz8YBk8jr5D5A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 826111806F4 for ; Wed, 21 Jan 2026 21:54:20 +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=ARC_SIGNED,ARC_VALID,BAYES_50, 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.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 ; Wed, 21 Jan 2026 21:54:18 +0000 (UTC) Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-5f524301a76so612801137.1 for ; Wed, 21 Jan 2026 13:54:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769032452; cv=none; d=google.com; s=arc-20240605; b=S0E6cvU5IFoirJIt/yTaNWbKkdQJKxRIGRdaRzFz7YFOagw8gFqFv/o0CncGiomkHQ OYBR34UfKxR9kavlpvwz+vmEugj5GlpccLQj2iLlc8Mgy9z2H92TxswapmW8/VeAPM3j Xy90Q2L/lW8eMgvxTtqBU/1KS3sorof8WtAYYOQJk1GwVsctWrPnJ88jQ0x1mXYgp8Zk koWFRylYv8zELwS+GffQI/rqW+zn7esBotsgRH26akZKa5Ot58M6k4EEMwNHgHo3A3x1 HBvmvAoN8Swoh7XDnuZ0pgdnFZ3nia511RIfKC3qG2j73sAJ5U3XwOtYagSITumUBUXH J5eA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=4IlGVf2hRwQ6sRa9HuEyMkbJ9Y3vS2icd83i6C2DeZk=; fh=J5MnZTiYttcUm8J4LNyR/rFPhZBFL0iiOf3qSYgVBBE=; b=K17yXcwuGmYPR5lWbYGqW3i4Pgsa1I+G/IccZM9FXHn2dS6pUwmumYk1ChvrbaFK4F TOSd34L16kSqUXMiAmhdWkCvQ6SXCfzIzq+hiqcc1Kq7T3y+Q4cV09AUpEevcWPakRrE 745kUTOXkxKG9Ny2xzAHLMTx2EjyL3oBt309S5vphrOr+uN3S/9WaT4B/ofz5s/Yixlp 4qmOH6fTOtzJd1J2VXMp6COuB/6UGmqHMkYayxb31DmLtamfrvok4wxCnZhQHfv9X+Ff UC7Oe/7s2vfs6cC4AXcyBjWNmQJOclhQST+zJXjQDmMHSZ9MC9zUlhBpgN2nKGhGot2Y Fyrw==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769032452; x=1769637252; 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=4IlGVf2hRwQ6sRa9HuEyMkbJ9Y3vS2icd83i6C2DeZk=; b=M82MVqifdCQ4rLutOD5ExZ5XDoODd3s90ESwphIMrtvBuxOlT7fiusnGOztEAW+43D bB/j5haKKk36hp/v8vc0U3wmlQtZiEArb++L58/uh2tjSn2IQwpTjszFCRCtHLyBErcX pD6YhDSCRpKk9lvqtk6cxPIcBdnLC7h0/5i4G2dMaVp0TrSXU8lzylXcqfT6BaXD06B7 to9fhU3VLpZfjmEJAhW+d11Jii8y9I/KCBFvbRRxivrU/jEPUn4FVHJ070Vn8rDDergS yyhzXUCxvA5KYZQBf1VBaALswY8cwnFnU9Bp8vBLFQk60Ei9p/h39+VWggSsMUJZ17oZ z0yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769032452; x=1769637252; 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=4IlGVf2hRwQ6sRa9HuEyMkbJ9Y3vS2icd83i6C2DeZk=; b=rJsyVTxEVFwS0wR5knZQVRwzGZJWtVnIE1ysxdllt4XqP/iUKIXyvqOT/YoAC/yTbq R/VMGugtit+PRp8YAmmuZ5fyTrFOn02PzuGXGoJavJzDrrtrvPZLD3Di4mdKCql5Bbp/ HHypz87T6L9gHwEorzF2TyjkiLqxzXU712iC6vktFdBE6WGoh5Cq+cCcXtu/cpOsJWQ7 zA/njxZi4poowsPz5d0BIUWgwjI0qEHFTJAkVpqIRVGbtOYU3y9CIjQ4tySoY7ch4jzV Gd5fx5O/we/pVRv4gKhWShPAP9/C0Xpyi+IF5AGNgPO9kfLG6sFyXtwvBG8qggDFDFeu rdlw== X-Gm-Message-State: AOJu0YyTQQrpJWcDX8LfcLOwkje93M/3WUBbujY2Zq+lQVB7um9TVbAP tEOrxbwK4N3N+kRxyi6xuGrihEockOsicW+SyYfpKX2BUUTknfHS2QyRfLDkcA2Y8BZAOJIHdn5 FKMUUFJiovv8/j6qM6jhyYIttgHgP9JQ= X-Gm-Gg: AZuq6aL4DOK4Brq4oKXLhLIfRipZ7IaEdYcbtxXj4SD30WvnRvQIH5aPStu0XhDce/u W8UWE0pJKqGJCVlFXrZryFya1kkPHK7QO+odIKq+Hw/ikFH+a5OQEOBpZtgWyTSOS94fBVvaezx WTJkOZQceBOh+8hgKKRYZmuMWuhQl4xGznCSqB80JP7V2I/ZqTon6uVm39RUGDrC4gu8ojCSifh HimwUEI61fkYnU4EWx/EUQenwnJ/u8yRJQjns7GtanMEbAlmcC0H1c1Y/gqdQIGCDZzDDam+vvW oTTVCO1cC38+IeaEVfCyOrGQt58= X-Received: by 2002:a05:6102:f13:b0:5ef:af68:e6bd with SMTP id ada2fe7eead31-5f532dec768mr337032137.2.1769032452420; Wed, 21 Jan 2026 13:54:12 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <79CDB2CC-E397-436E-B5A2-10DA1E451A97@rwec.co.uk> In-Reply-To: Date: Wed, 21 Jan 2026 23:54:01 +0200 X-Gm-Features: AZwV_QgYAZRvAl_Gj2vS_XW7v5zGJfjnuZbZvRSGyA_C75p67Dq848FUBUeUYRU Message-ID: Subject: Re: [PHP-DEV] Re: [RFC] True Async RFC 1.7 To: Deleu Cc: php internals Content-Type: multipart/alternative; boundary="000000000000ec38ba0648ecf668" From: edmond.ht@gmail.com (Edmond Dantes) --000000000000ec38ba0648ecf668 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable P.s Oh right. I=E2=80=99d like to say a bit about how I feel, because there wer= e assumptions here that I=E2=80=99m frustrated. Okay. I am not frustrated. I usually look at the current situation and understand how it works from the inside. Why? The thing is, rockets are exploding around me and so on. And then suddenly the question arises: someone in the world thinks differently. So what? Honestly? It doesn=E2=80=99t matter much. The world is inherently imperfect. Programming is not based on proofs. People constantly make various irrational decisions. It has always been that way and it always will be. And that is completely normal. You don=E2=80=99t get angry at rain, do you? Or snow? I also don=E2=80=99t = feel anger toward natural things. Everyone will make their own choice. I=E2=80=99ve already made mine. In tha= t sense, I=E2=80=99m comfortable. Those who will be voting have a much harder task. =D1=81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 23:41 Edmond Dan= tes : > I never said that any projects were adapted for Swoole. Moreover, whether > they were adapted or not is a slightly different discussion. I was only > saying that the impact is well known. For example, it is well known how > coroutines affect Laravel. It is also well known that Laravel does not > support coroutines. > > Participation in the vote presupposes a minimal level of programming > literacy. This is not an insult, but an attempt to remind of that. It is > clear that it is impossible to be an expert in all areas, but it is also > impossible to make a decision without understanding. > > An RFC has two levels of complexity: the first and the second. The first > level is simple enough to be understandable by any programmer. Transparen= t > asynchrony and coroutines are not something that cannot be understood. > > We have come to live in a society where everyone is very eager to take > offense, instead of thinking about important things. I like to think abou= t > something. > > > > =D1=81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 23:24 Deleu : > >> >> >> On Wed, Jan 21, 2026 at 5:42=E2=80=AFPM Edmond Dantes >> wrote: >> >>> If that were the case. But it isn=E2=80=99t. >>> >> >> Let's agree to disagree. >> >> >>> For example, the Swoole project has existed for more than 7 years. This >>> means that anyone here can check how coroutines actually affect their c= ode. >>> >> >> And in those 7 years, it hasn't been adopted by 100% of PHP projects. In >> fact, I'd take a wild guess that its adoption is very likely below 20% o= f >> PHP projects out there. Just because it exists doesn't mean every PHP >> Software Engineer would benefit from it or that it's undeniably useful f= or >> any project or business. I first heard of Swoole in 2020. Ever since, I'= ve >> had the desire to try it out, but never had a business case for it. If y= our >> RFC requires people to dive deep into knowing Swoole and understanding h= ow >> it works and how it affects everyone's code, I would consider that to be >> one of the top reasons why the RFC hasn't gotten more traction. >> >> >>> There is already extensive experience with Laravel and other >>> applications. >>> All of this has existed for a long time. >>> >> >> Just because it has existed doesn't mean it is universally used. >> >> >>> If people cannot read the RFC and understand that these are >>> JavaScript-style coroutines, then why do they have votes? =F0=9F=99=82 = That=E2=80=99s a >>> strange idea. >>> >> >> I see this statement as you going out of your way to offend the very >> people that have the power to vote on your RFC. They have a vote because >> they have contributed to the ecosystem of PHP enough to have a vote. An >> ecosystem that has existed without Async PHP for 3 decades. An ecosystem >> that requires thorough development, documentation, release, testing, bug >> fixing, security fixing. They have volunteered their time in proposing >> changes, getting those changes ironed out, implemented, adopted. They ha= ve >> improved the language. Just because they don't have your level of knowle= dge >> in asynchronous programming does not make their contribution any less >> meaningful or any less important. >> >> I can understand and sympathise that it must be very frustrating for you >> to put so much thought and care into this proposal and have no clear pat= h >> as to how to make it land on PHP Core. But that is not an excuse to offe= nd >> contributors of the project, especially given how narrow the subject mat= ter >> is. There's definitely an appetite to have Async PHP and you're not goin= g >> to get anybody on your side by implying that they are the problem in >> understanding your RFC. This is not a "one or another person" problem. >> There are plenty of extremely smart people participating in the developm= ent >> of PHP for years. How can the RFC be easy to digest so that they can >> participate more? >> >> >>> Yes, there are issues with understanding. However, a year has passed >>> since the publication. In one year, it should have been possible to cla= rify >>> any questions, if there were any. >>> >> >> The RFC is complex enough that giving it chunks of 30 minutes spread >> across many weeks is not enough to put forward every question that it >> warrants. 1 year or 10 years is not going to solve that. >> >> In other words, if PHP had never had such coroutines, that could be >>> understood. But the situation is exactly the opposite. >>> >>> As for trust, the problem is that people don=E2=80=99t want to waste th= eir time. >>> They don=E2=80=99t want to play for a team with no chance of success. >>> >> >> I see no evidence of that. There is no one team vs another here. The >> change either lands or it doesn't. Being such a promising change to the = PHP >> Ecosystem, it would be in any volunteer's interest to have been able to >> participate and shape the biggest change in the PHP Language in decades. >> But its not about "wasting time because its a loss cause". Its about not >> having volunteering time to grasp such a hard RFC. >> >> What can be done? A lot of things can be done. Last time there were >>> several proposals. But all of these proposals go beyond the scope of th= e >>> RFC. They require organizational changes. >>> >>> I can once again propose having two votes and an experimental mode. >>> The first vote would be on the core principles of the language=E2=80=99= s >>> development for the next 5=E2=80=9310 years. >>> A vote on this RFC. >>> Or another option. There is more than one. For example, you could vote >>> in a first approximation, and then a year later in a second round. >>> >>> So... >>> >>> =D1=81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 22:15 Deleu = : >>> >>>> >>>> >>>> On Wed, Jan 21, 2026 at 4:29=E2=80=AFPM Edmond Dantes >>>> wrote: >>>> >>>>> Regarding the group, I want to once again express an important point. >>>>> The main problem, the primary blocking issue, is that nobody believes >>>>> this RFC has any real chance. >>>>> >>>>> It=E2=80=99s like in the banking system: if you convince people that = stocks >>>>> will fall, then even if it=E2=80=99s not true, the stocks will fall. >>>>> >>>>> At the same time, I agree with this assessment. >>>>> We are facing a paradox. >>>>> >>>>> To make changes to the language, you need to believe that these >>>>> changes can be accepted. Previously, there were doubts about whether >>>>> such changes could even be implemented. That problem has been solved. >>>>> What remains is the lack of trust in acceptance. >>>>> How can this be resolved? I think there are ways, and they are known. >>>>> They are just all outside the scope of the current RFC. >>>>> >>>>> ---- >>>>> Ed >>>>> >>>> >>>> I doubt the problem is about trust. You can trust that a company will >>>> not go bankrupt, you still need to understand how to operate and buy >>>> stocks. I think most readers are more likely to agree that you've put = a >>>> tremendous amount of work forward and it's not that hard to trust you'= ve >>>> done a great job so far. But if we don't know how things work, we can'= t >>>> help you make even better decisions nor can we make use of what you've >>>> built. >>>> >>>> I also don't think it's fair to expect from PHP's RFC process a >>>> position of: "trust me, this is the best, lets just merge it". Even if= you >>>> were the best and smartest software engineer in the world, PHP is used= by >>>> an immeasurable amount of people from all backgrounds, in many context= s and >>>> many approaches. Its not humanly possible for a single individual to k= now >>>> every possible way PHP is used and the RFC process is here for people = from >>>> many backgrounds to provide their own perspective of things and voice = how >>>> they think such a change will affect them or their project - be it a >>>> positive or a negative impact. >>>> >>>> Right now, I think the "fairest" assumption is that we don't have many >>>> such voices because nobody can read, understand, interpret and predict= how >>>> this RFC would play out in their projects and their work. It's far too= big >>>> of a change with too many concepts, mainly foreign to many people work= ing >>>> with PHP and there isn't a clear path of contributing to the discussio= n. >>>> >>>> How do we solve that? >>>> >>>> -- >>>> Marco Deleu >>>> >>> >> >> -- >> Marco Deleu >> > --000000000000ec38ba0648ecf668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
P.s

Oh right= . I=E2=80=99d like to say a bit about how I feel, because there were assump= tions here that I=E2=80=99m frustrated.
Okay. I am n= ot frustrated. I usually look at the current situation and understand how i= t works from the inside.
Why? The thing is, rockets = are exploding around me and so on. And then suddenly the question arises: s= omeone in the world thinks differently. So what?
Hon= estly? It doesn=E2=80=99t matter much.
The world is = inherently imperfect. Programming is not based on proofs. People constantly= make various irrational decisions. It has always been that way and it alwa= ys will be. And that is completely normal.
You don= =E2=80=99t get angry at rain, do you? Or snow? I also don=E2=80=99t feel an= ger toward natural things.
Everyone will make their = own choice. I=E2=80=99ve already made mine. In that sense, I=E2=80=99m comf= ortable. Those who will be voting have a much harder task.

<= div class=3D"gmail_quote gmail_quote_container">
=D1=81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 23:41= Edmond Dantes <edmond.ht@gmail.c= om>:
I never said that any projects were adapted for Swoole. Moreov= er, whether they were adapted or not is a slightly different discussion. I = was only saying that the impact is well known. For example, it is well know= n how coroutines affect Laravel. It is also well known that Laravel does no= t support coroutines.

Particip= ation in the vote presupposes a minimal level of programming literacy. This= is not an insult, but an attempt to remind of that. It is clear that it is= impossible to be an expert in all areas, but it is also impossible to make= a decision without understanding.

An RFC has two levels of complexity: the first and the second. T= he first level is simple enough to be understandable by any programmer.=C2= =A0Transparent asynchrony and coroutines are not something that cannot be u= nderstood.

We have come = to live in a society where everyone is very eager to take offense, instead = of thinking about important things. I like to think about something.=C2=A0<= /div>



=D1=81=D1=80, = 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 23:24 Deleu <del= eugyn@gmail.com>:


On Wed, Jan 21, 2026 at 5:42=E2=80=AFPM Edmon= d Dantes <edmond.ht@gmail.com> wrote:
<= /div>
If that were the case. But it isn=E2=80=99t.

Let's agree to disagree.
=C2=A0=
<= div dir=3D"auto">
For example, the Swoole project has exis= ted for more than 7 years. This means that anyone here can check how corout= ines actually affect their code.

And in those 7 years, it hasn't been adopted by 100% of PHP pro= jects. In fact, I'd take a wild guess that its adoption is very likely = below 20% of PHP projects out there. Just because it exists doesn't mea= n every PHP Software Engineer would benefit from it or that it's undeni= ably=C2=A0useful for any project or business. I first heard of Swoole in 20= 20. Ever since, I've had the desire to try it out, but never had a busi= ness case for it. If your RFC requires people to dive deep into knowing Swo= ole and understanding how it works and how it affects everyone's code, = I would consider that to be one of the top reasons why the RFC hasn't g= otten more traction.
=C2=A0
The= re is already extensive experience with Laravel and other applications.
All of this has existed for a long time.

Just because it has existed doesn't= mean it is universally used.
=C2=A0
If people cannot read the RFC and understand that these are JavaScrip= t-style coroutines, then why do they have votes? =F0=9F=99=82 That=E2=80=99= s a strange idea.

I see t= his statement as you going out of your way to offend the very people that h= ave the power to vote on your RFC. They have a vote because they have contr= ibuted to the ecosystem of PHP enough to have a vote. An ecosystem that has= existed without Async PHP for 3 decades. An ecosystem that requires thorou= gh development, documentation, release, testing, bug fixing, security fixin= g. They have volunteered their time in proposing changes, getting those cha= nges ironed out, implemented, adopted. They have improved the language. Jus= t because they don't have your level of knowledge in asynchronous progr= amming does not make their contribution any less meaningful or any less imp= ortant.

I can understand and sympathise that it mu= st be very frustrating for you to put so much thought and care into this pr= oposal and have no clear path as to how to make it land on PHP Core. But th= at is not an excuse to offend contributors of the project, especially given= how narrow the subject matter is. There's definitely an appetite to ha= ve Async PHP and you're not going to get anybody on your side by implyi= ng that they are the problem in understanding your RFC. This is not a "= ;one or another person" problem. There are plenty of extremely smart p= eople participating in the development of PHP for years. How can the RFC be= easy to digest so that they can participate more?
=C2=A0
Yes, there are issues with understanding. Howev= er, a year has passed since the publication. In one year, it should have be= en possible to clarify any questions, if there were any.
<= /blockquote>

The RFC is complex enough that giving it ch= unks of 30 minutes spread across many weeks is not enough to put forward ev= ery question that it warrants. 1 year or 10 years is not going to solve tha= t.=C2=A0

In other words, i= f PHP had never had such coroutines, that could be understood. But the situ= ation is exactly the opposite.

As for trust, the problem is that people don=E2=80=99t want to waste= their time. They don=E2=80=99t want to play for a team with no chance of s= uccess.

I see no evidence= of that. There is no one team vs another here. The change either lands or = it doesn't. Being such a promising change to the PHP Ecosystem, it woul= d be in any volunteer's interest to have been able to participate and s= hape the biggest change in the PHP Language in decades. But its not about &= quot;wasting time because its a loss cause". Its about not having volu= nteering time to grasp such a hard RFC.

What can be done? A lot of things can be done. Last time ther= e were several proposals. But all of these proposals go beyond the scope of= the RFC. They require organizational changes.

<= /div>
I can once again propose having two votes and an exp= erimental mode.
The first vote would be on the core = principles of the language=E2=80=99s development for the next 5=E2=80=9310 = years.
A vote on this RFC.
Or= another option. There is more than one. For example, you could vote in a f= irst approximation, and then a year later in a second round.

So...=C2=A0

=D1=81=D1=80, 21 =D1= =8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 22:15 Deleu <deleugyn@gmail.com>:


On Wed, Jan = 21, 2026 at 4:29=E2=80=AFPM Edmond Dantes <edmond.ht@gmail.com> wrote:
Regarding the group, I want to once agai= n express an important point.
The main problem, the primary blocking issue, is that nobody believes
this RFC has any real chance.

It=E2=80=99s like in the banking system: if you convince people that stocks=
will fall, then even if it=E2=80=99s not true, the stocks will fall.

At the same time, I agree with this assessment.
We are facing a paradox.

To make changes to the language, you need to believe that these
changes can be accepted. Previously, there were doubts about whether
such changes could even be implemented. That problem has been solved.
What remains is the lack of trust in acceptance.
How can this be resolved? I think there are ways, and they are known.
They are just all outside the scope of the current RFC.

----
Ed

I doubt the problem is= about trust. You can trust that a company will not go bankrupt, you still = need to understand how to operate and buy stocks. I think most readers are = more likely to agree that you've put a tremendous amount of work forwar= d and it's=C2=A0not that hard to trust you've done a great job so f= ar. But if we don't know how things work, we can't help you make ev= en better decisions nor can we make use of what you've built.

I also don't think it's fair to expect from PHP'= ;s RFC process a position of: "trust me, this is the best, lets just m= erge it". Even if you were the best and smartest software engineer in = the world, PHP is used by an immeasurable amount of people from all backgro= unds, in many contexts and many approaches. Its not humanly possible for a = single individual to know every possible way PHP is used and the RFC proces= s is here for people from many backgrounds to provide their own perspective= of things and voice how they think such a change will affect them or their= project - be it a positive or a negative impact.

= Right now, I think the "fairest" assumption is that we don't = have many such voices because nobody can read, understand, interpret and pr= edict how this RFC would play out in their projects and their work. It'= s far too big of a change with too many concepts, mainly foreign to many pe= ople working with PHP and there isn't a clear path of contributing to t= he discussion.

How do we solve that?
--
Mar= co Deleu


--
Marco Deleu
--000000000000ec38ba0648ecf668--