Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121033
MIME-Version: 1.0
References: <CAPyj-LB16MUDNkgdQ7TrHpgNG2gD86H7+OP_g_rbuH0KYR9ZzQ@mail.gmail.com>
 <CADK1yXKALob62e7QA2AyxDmX6xFk3tLkUgy2-e55nVEeKK=6xw@mail.gmail.com> <07AD80D5-BC71-43DE-B5B1-FDAF82BD9439@gmail.com>
In-Reply-To: <07AD80D5-BC71-43DE-B5B1-FDAF82BD9439@gmail.com>
Date: Sun, 10 Sep 2023 14:47:24 -0300
Message-ID: <CADK1yXLE-BuBjKy6W04r+HvsDaChvqscGu6a5QTcUeQSNp89Og@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008f7b12060504cfaf"
Subject: Re: [PHP-DEV] [RFC][Draft] Match block
From: deleugyn@gmail.com (Deleu)

--0000000000008f7b12060504cfaf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 10, 2023 at 12:51=E2=80=AFPM Rowan Tommins <rowan.collins@gmail=
.com>
wrote:

> On 10 September 2023 15:35:44 BST, Deleu <deleugyn@gmail.com> wrote:
> > ... until we manage to gather enough
> >voters to overcome the "no-auto-capture" camp.
>
>
> I think that's a rather adversarial / political way to put it. I believe
> the aim of voting should be to measure consensus, not replace it.
>

Communities are a live organism and I reckon the current pool of voters are
not exactly the same as the ones voting 15 years ago. Even if someone used
to be an active voter 15 years ago and is still present to this day, maybe
their mindset or the language itself has changed enough to yield a
different result. What I meant to say with "enough voters to overcome the
no-auto-capture camp" is that the current camp that blocks this line of
reasoning can either change their mind, disengage from the project
(reducing no-votes) or simply be outvoted by a new wave of contributors.


> A more productive wording would be "until we can find a version of the
> feature that satisfies the concerns raised in previous discussions".
>

I think this is wishful thinking as the previous discussions has already
shown that the disagreement is fundamental. What I want is =3D=3D=3D
auto-capture. I don't want something that resembles auto-capture or
facilitates capturing. Previous discussion has already established that one
camp of voters don't want auto-capture. They might be open to a compromise
on facilitating auto-capture, which is where there's no expectation of a
version which satisfies the concerns.


I think there are some really powerful things that could be done with new
> types of block, and new ways of scoping variables, but have concerns abou=
t
> how to fit them with the existing language. I will continue to engage in
> good faith in discussing those proposals, but find it disheartening to be
> labelled as part of a "camp" that needs to be "overcome".


I meant no disrespect and I apologize for any negative effect that my
wording may have caused. I do have difficulty expressing it differently.
There's this core concept which I see as a great improvement to the
development of PHP code and there's philosophical disagreement on whether
it's a good thing or not. Perhaps there is really no *need* to overcome
that camp of voters and maybe they are what's protecting the language from
walking towards a bad path. We just have no way of settling this. In such
fundamental disagreement, someone is bound to be unsatisfied with the
outcome. Either we will manage to get auto-capture and see if it leads to a
bad outcome or we won't have it. Either not having it is protecting the
language or not having it is preventing a great step forward. There's no
experiment, feature-flag or time-machine options.

... I can't help but see the irony that auto-capturing would create
something "alien" to the PHP language and since we don't have that, there's
a new proposal to create a different "alien" concept which is a
kind-of-return within a block statement that doesn't exactly mean "return"
(the <- token / resolve keyword).

--=20
Marco Deleu

--0000000000008f7b12060504cfaf--