On Fri, Aug 14, 2020 at 9:48 AM Sara Golemon <poll...@php.net> wrote:
> On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown <theodor...@outlook.com> wrote: > > 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. > > Yes. Derick fucked up the *letter* of the rule here. His intentions > were good and reasonable (God knows we've discussed this agonizing > topic for far longer than two weeks), but taking the RFC in question > in a vacuum, it is well under two weeks. By the *intent* of the rule, > he's fine. This has been discussed exhaustively. > > > How can the vote result be considered legitimate or binding? > > Exhaustingly, I do agree. Contentious times call for careful outcomes. > > > 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). > > I'd say as late as the 21st. Minimize doubt in the process. > > > 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 > > Glancing at beberlei's reply, I do agree that @: is coming slightly > out of left field. However, we're using a STV system, so might as > well go wild with the options (within reason). HOWEVER, any option > included is going to need the same care applied as you outline in #3 > and #4 below. Thanks Sara. So it sounds like voting will be stopped/reset until the 21st (a week from today), to give time to update the RFC and include the @: syntax option in the STV polls? > > 3. Add a Backward Incompatible Changes section with examples of the > > code that the different syntax options would break. > > More information is better than less. +1 > > > 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). > > 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. > > I'd be willing to help draft this section if the RFC authors so desire. > > I say "don't ask to ask", just send some suggested text (or put up a > gist) and let them copy it in if they want. Okay, I drafted an initial summary of discussion arguments here: https://gist.github.com/theodorejb/2d39eb6e13159fc749f728900edfd0d2 > Honestly, the current end date is fine, because the intent of the rule > is met. However, I do like that you're seeking a solution which helps > to put concerns to rest. The only part which irks me is that we have > 50-some votes already cast that would be thrown out and have to be > redone, and that's on what is already the 3rd vote on this syntax. > I'm vote fatigued, personally. However, we're going to have to live > with this syntax forever once it's out, so we should believe that we > believe in it. Agreed. Regardless of final syntax outcome, ensuring the process isn't rushed can provide confidence that the right decision is being made. Kind regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
