On Sun, Sep 10, 2023 at 12:51 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On 10 September 2023 15:35:44 BST, Deleu <deleu...@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 === 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 about > 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). -- Marco Deleu
