On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison <levi.morri...@datadoghq.com> wrote:
> > So, a week+ early, then? Surely that means the current vote null > > and void, to be reset entirely following a proper discussion period > > -- one without concurrent voting. > > I just want to make sure I understand: there are people who think we > haven't discussed the syntax for attributes yet? > > I assume this is a serious email, but I can't fathom why anyone cares. > We've discussed this subject soo much... Hi Levi and internals, 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). 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 3. Add a Backward Incompatible Changes section with examples of the code that the different syntax options would break. 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. Derick and Benjamin (and Sara), are these requests reasonable? If the RFC follows the discussion period rule and contains all the relevant information, I will be much more confident that it is resulting in the best long term outcome (and I think this would speak for many others on list as well). Sincerely, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
