Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111517
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008100935570.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB65355FFBB6717491995EEBF4DE420@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CAESVnVqraG9V4VMrxrv5AOFX5Jt7Cx0-uo5L0doQEWcUVOdHkg@mail.gmail.com>
 <BYAPR05MB65356FCC029CD06F49F528A0DE420@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CABdc3WobP1HSRwcujd4=o4wv3QUp7gDT12KmMRQU1_wLj4YLuQ@mail.gmail.com>
 <BYAPR05MB65351C807797676BB08D8BDCDE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <5cc837df-ab47-628a-d29b-46d7933be973@gmx.net> <BYAPR05MB653522F9123B59F7E066BDB8DE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <3A7CECC3-CDEE-4852-BF4B-4EC7CA1BD538@pmjones.io> <CAAKU0u=VYh7D+XJ93dDdAxdJ8nEU8iPfeN0f=Xv9Qm=cCQKX6w@mail.gmail.com>
 <BN8PR05MB6532D19BEA11F44BAAD3FDD3DE400@BN8PR05MB6532.namprd05.prod.outlook.com>
In-Reply-To: <BN8PR05MB6532D19BEA11F44BAAD3FDD3DE400@BN8PR05MB6532.namprd05.prod.outlook.com>
Date: Fri, 14 Aug 2020 09:48:42 -0500
Message-ID: <CAESVnVp5NHKKpMHt_7AAO8P9L2vL8UN4ynD5K4d9f23Jvr+s2A@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, Derick Rethans <derick@php.net>, 
	Benjamin Eberlei <kontakt@beberlei.de>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000012720305acd78527"
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: pollita@php.net (Sara Golemon)

--00000000000012720305acd78527
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown <theodorejb@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.


> 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.
>
>
Derick was trying to be good and meet my beta3 deadline.  Fortunately, I
gave him that deadline (while thinking RC1) knowing some kind of bullshit
like this would come up and LO AND BEHOLD here we are.  So the good news is
that we actually have a spare two weeks.



> 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.


> 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

Re (berberlei) """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"""

Agree that I wouldn't have thought it necessary.   These "breaks" are
trivial for a few lines of script to find and fix.


> 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.

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).
>
>
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.

-Sara

--00000000000012720305acd78527--