On Fri, Aug 14, 2020 at 9:16 AM Benjamin Eberlei <kont...@beberlei.de> wrote:
> On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown <theodor...@outlook.com> wrote: > > There's certainly been a lot of discussion in general about > > attributes. However, there was not a reasonable opportunity to either > > discuss the specific arguments made in this RFC (e.g. the lack of a > > closing symbol being inconsistent), or submit patches for alternative > > syntaxes as Derick requested when he put up the RFC for discussion. > > > > I was very surprised that it went to vote less than six days after > > the discussion period started, right after the weekend no less, > > before I had a chance to submit my patch to include the @: syntax. > > > > I'm as weary of the discussion as anyone, and would like to see > > closure on this topic sooner rather than later. But if the voting > > rules aren't followed, how can the vote result be considered > > legitimate or binding? > > > > If the authors sincerely want the best outcome for the language (and > > I assume they do), what harm is there in deferring the vote until the > > discussion period has completed, and ensuring that the RFC addresses > > the arguments on both sides and contains all the relevant information > > for making a decision? Otherwise many contributors (myself included) > > just end up feeling unheard, unhappy, and unconfident that the right > > choice is being made. > > > > With this in mind, I'd like to respectfully make the following > > requests: > > > > 1. Defer voting until the two week discussion period is complete > > (Tuesday, August 18). > > What do you mean by defer exactly? Stop voting or reset the vote? > We were thinking of extending the vote until September 1st. Hi Benjamin, Yes, my request is to stop/reset the vote until after the discussion period is complete. Otherwise few people will see the updates made to the RFC since they already voted. > > 2. Include a ranked voting option for @: and mention its pros and > > cons (it is equally concise as @@ with no BC break, but is somewhat > > harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1 > > I am wondering where @: is suddenly coming from? It wasn't discussed > in both shorter attributes RFC and the discussion leading to this RFC. @: wasn't included in the Shorter Attribute Syntax RFC because I didn't realize it was allowed to re-vote on a failed secondary poll after less than six months. However, since we're re-voting on #[] I think it's only fair to include @: as well - some people may prefer a short syntax but dislike the specific look of @@. Personally I would like to vote for @@ as my first preference and @: as my second. > There were a few other suggestions like $() or "using attribute", but > none of them was followed up upon. Nobody replied to my or Dericks > message with a specific interest in actually contributing another patch, > including @: I hadn't replied to this part of Derick's message yet because the voting started before I had a chance to write the patch. > > 3. Add a Backward Incompatible Changes section with examples of the > > code that the different syntax options would break. > > Derick and I are working on this section to update the RFC later today. > We didn't consider this relevant, because the mitigation steps for all > of them is the same: a project wide search and replace to insert a space Thank you for working on this. The mitigation for current usages of @@ should be to delete the extra symbol rather than adding a space (though I'm very doubtful that any usages of @@ even exist currently, since extra suppression operators don't do anything useful). The main benefit of the BC break section will be to highlight examples of how @[] and #[] break syntax that is both valid and useful, while @@ does not. > > 4. Add a Discussion section briefly summarizing the arguments that > > have come up on list. In particular this should include: > > a) Tyson's examples of #[] changing the meaning of code in > > unexpected ways between PHP 7 and 8 (e.g. a parameter > > attribute would remove the parameter when run on PHP 7). > > This is also included in the update, but ultimately is covered by the > explanation for "Forward Compatibility" already mentioning that it > does only work with a subset (and hence does not work for some other > subset). Okay, but I think examples are necessarily to illustrate which subset of the new syntax works and what does not. It certainly wasn't clear to me before I saw Tyson's examples. > > b) An example of the downside of grouping, where it causes > > unnecessary diff noise when adding or removing a second > > attribute on its own line. > > This is a problem for coding styles to solve and is nothing the RFC > should be concerned with. Grouped syntax specifically includes support > [for] trailing commas. Diff noise is something all declarations with > optional elements can cause, even use of @@ in one line can be "forced" > from single to multi lines creating diff noise under reasonable Coding > Standard assumptions. Even if you "force" an attribute with @@ across multiple lines, that individual attribute can still be added/removed without modifying the attributes on other lines. On the other hand, with grouping the only way to avoid modifying extra lines when adding/removing a second attribute would be to mandate that the first attribute always be written like this: #[ SomeAttribute, ] function foo() {} But this also makes diffs noisier since at the very start two extra lines have to be included. Best regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
