Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111502
To: =?iso-8859-2?Q?Micha=B3_Marcin_Brzuchalski?=
	<michal.brzuchalski@gmail.com>
CC: Sara Golemon <pollita@php.net>, PHP Developers Mailing List
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
Thread-Index: AQHWbvIBydbCX+rhJUWK/r8c7hnlt6k0kNaHgAALBwCAAAp7tYABDvUAgABUQtk=
Date: Thu, 13 Aug 2020 13:17:13 +0000
Message-ID:
 <BYAPR05MB65351C807797676BB08D8BDCDE430@BYAPR05MB6535.namprd05.prod.outlook.com>
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>
In-Reply-To:
 <CABdc3WobP1HSRwcujd4=o4wv3QUp7gDT12KmMRQU1_wLj4YLuQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [MdRCRl27t5xuaVk3zKbzhwvRiC+qklW4]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 88460d11-73ba-48d2-5a23-08d83f8b3195
x-ms-traffictypediagnostic: BN1NAM02HT190:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 HWOT33FFYjj42+HiGqtjS7Ee3E1zJBQmWHfQ3pD9FMslPmd3T52lU4gLeGIIvalUAUAPKx6pMItqJ6ecNGAZM8LnCQu99Uf7Ucp0BwNfyfhuRzszUosWMCiD2QmXxIwv6shcJk/mJFI0Iwy49ws5JNcf4v3iqIXAUFR4ibaTrkdarN17NxfrnrbrpxtiptkgUYiMoB4vw/jsQ0U2yhx1bvLShtmTEX7dDV5PFqlAYQHwOia+l0rMdbwksvmSaQW1
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR05MB6535.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 zFKxptTBOV6i/4fw8EYbpKJgKOiD2UGJGoX1FlpeAbJa25F1EEskZETSyKH5U693YXq0EtE9NoeNExd4yPEvvIl76nvHkgA0EgfDtBO7OHM6wdnWeZZuEpb/98FWdti5J4J0XOzRFT0lzHH3qLK64w==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT007.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 88460d11-73ba-48d2-5a23-08d83f8b3195
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 13:17:13.6811
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1NAM02HT190
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: theodorejb@outlook.com (Theodore Brown)

On Thu, Aug 13, 2020 at 3:13 AM Micha=B3 Marcin Brzuchalski <michal.brzucha=
lski@gmail.com> wrote:=0A=
=0A=
> Hi Theodore,=0A=
> =0A=
> =B6r., 12 sie 2020 o 18:36 Theodore Brown <theodorejb@outlook.com> napisa=
=B3(a):=0A=
> > On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon <pollita@php.net> wrote:=
=0A=
> > =0A=
> > > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote:=0A=
> > >=0A=
> > > > It has just come to my attention that this RFC was rushed to vote=
=0A=
> > > > after less than the minimum two week period required after it was=
=0A=
> > > > brought up on list. Furthermore, discussion was still very active a=
t=0A=
> > > > that time - I certainly didn't have a chance to respond to some of=
=0A=
> > > > the emails before voting began.=0A=
> > > >=0A=
> > > > Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and th=
e=0A=
> > > > vote was started this Monday at 3:41 AM, less than 12 days, 18 hour=
s=0A=
> > > > after the announcement. Per the voting rules:=0A=
> > >=0A=
> > > So, 30 hours short of 2 weeks. I'm going to ascribe good intentions=
=0A=
> > > in trying to get the issue resolved in the minimal timeframe. The=0A=
> > > fact active discussion was ongoing makes this a questionable choice,=
=0A=
> > > but in my opinion, purely on a matter of time, quibbling over 30 hour=
s=0A=
> > > is splitting hairs. Maybe compromise on adding time to the vote end=
=0A=
> > > period so that the total is greater than 4 weeks?=0A=
> > >=0A=
> > > > What should be done to prevent this rule from being violated?=0A=
> > >=0A=
> > > Vigilance. You're right to raise the concern. And let's wag a finger=
=0A=
> > > over it at least. If others agree that it's premature, we can stop=0A=
> > > the vote, but I'm not inclined to disrupt the process over such a=0A=
> > > small variance.=0A=
> > =0A=
> > On top of violating the minimum two week discussion period, I believe=
=0A=
> > this RFC also breaks the rule on resurrecting failed proposals. When=0A=
> > I authored the Shorter Attribute Syntax RFC, I specifically did not=0A=
> > include a voting option for `@:`, since this syntax was declined,=0A=
> > and my understanding was that a six month waiting period is required=0A=
> > before resurrecting rejected proposals. [1]=0A=
> > =0A=
> > But if we can vote again on `#[]` and `<<>>` after they were declined,=
=0A=
> > why can't we also vote again for `@:`? This syntax has the advantage=0A=
> > of being equally short as `@@` without any BC break.=0A=
> > =0A=
> > I'm really disappointed and disillusioned with how the process has=0A=
> > been handled for this RFC. It seems like the rules are arbitrarily=0A=
> > going out the window in order to keep voting until the desired result=
=0A=
> > is reached.=0A=
> > =0A=
> > What is the point of having rules if they aren't followed or enforced?=
=0A=
> > If anyone else is troubled by the precedent being set by this RFC,=0A=
> > please vote No on the primary vote. I'm not sure what other recourse=0A=
> > we have at this point.=0A=
> > =0A=
> > Sincerely,=0A=
> > Theodore=0A=
> > =0A=
> > [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals=0A=
> =0A=
> You hint to the fact of shorter discussion period and the fact that=0A=
> you haven't got time to respond to all discussions while if you take=0A=
> a closer look on ML [4] that is obvious that discussion in fact began=0A=
> earlier and it's 3 weeks from now and to avoid insinuation you replied=0A=
> to it [5] 3 weeks ago as well.=0A=
=0A=
Hi Micha=B3,=0A=
=0A=
The discussion thread you're referencing did not announce an RFC. Per=0A=
the voting rules, a "Proposal is formally initiated by creating an=0A=
RFC on PHP wiki and announcing it on the list". After that there must=0A=
be a minimum two week discussion period before voting starts. The=0A=
Shorter Attribute Syntax Change RFC failed to meet this requirement.=0A=
=0A=
> Rejected features have nothing to do with a re-vote on a syntax=0A=
> change at least this is how I understand this. Besides you already=0A=
> mentioned this argument on ML [1] so we can argue actually if a=0A=
> re-vote on syntax change is actually resurrecting a declined=0A=
> proposal since it was not a standalone proposal which got into a=0A=
> declined section of RFC's index [2] and yet you did it again!=0A=
=0A=
So you're saying that the rule on resurrecting failed proposals only=0A=
applies to primary votes, and not secondary votes? So if a secondary=0A=
vote fails it's okay to vote for it again and again until the desired=0A=
result it reached? This is not my understanding of the rules.=0A=
=0A=
> You blame others for "abusing" the RFC process while you've brought=0A=
> to us an RFC with a significant ambiguity [3] which you haven't=0A=
> mention and it turned out after closing a vote. Personally I think=0A=
> that it was your huge failure to bring the previous @@ syntax change=0A=
> RFC up to the voting without checking it's correctness.=0A=
=0A=
It was correct as far as we knew at the time. Anyway, this issue was=0A=
fixed before the @@ syntax was merged, and I don't see its relevance=0A=
to this discussion.=0A=
=0A=
> I'm personally also disappointed with the fact that in your RFC under=0A=
> the primary vote question "Are you okay with re-voting on the=0A=
> attribute syntax for PHP 8.0?" removing features like grouping=0A=
> ability was hidden.=0A=
=0A=
I don't follow you. The grouping feature for <<>> wasn't even accepted=0A=
yet when the Shorter Attribute Syntax RFC went to vote. One of the=0A=
primary motivations of the Shorter Attribute Syntax RFC was to reduce=0A=
verbosity and remove the need for two different syntaxes (grouped and=0A=
non-grouped) for declaring attributes. It was also discussed on list=0A=
how @@ is equally or more concise without grouping:=0A=
https://externals.io/message/110355#110414. Finally, the Attribute=0A=
Amendments RFC itself explicitly stated that the grouped attribute=0A=
feature "would be superseded by any other RFC getting accepted that=0A=
changes the syntax."=0A=
=0A=
Attribute grouping makes some sense to help reduce the verbosity of=0A=
the @[], #[], and especially <<>> syntaxes, but with @@ there is no=0A=
need for the extra complexity since it is equally concise without it.=0A=
=0A=
> Personally I think you're forcing to stop the re-vote cause of mental=0A=
> connection to your previous @@ RFC and trying hard to find an argument=0A=
> against the re-vote. From the results which are available so far, it=0A=
> can be seen that your proposed syntax is no longer the leading one.=0A=
> I understand it fully cause I'd be upset as well.=0A=
=0A=
If it was just a matter of my personal syntax preference I wouldn't=0A=
be having this discussion. I was fine with voting on #[] originally=0A=
and included it as an option in the Shorter Attribute Syntax RFC.=0A=
=0A=
What I have a serious problem with is breaking rules to arbitrarily=0A=
vote again in the hopes that this time voters will choose #[] even=0A=
though it was declined in the last vote. Moreover, the current RFC=0A=
does not fairly present all the pros and cons of each syntax, and=0A=
the requests of myself and others to include additional important=0A=
details in the RFC about the BC breaks and other considerations have=0A=
not been heeded.=0A=
=0A=
What is happening here is wrong, and because I want the best for PHP=0A=
I have to stand up to it.=0A=
=0A=
Sincerely,  =0A=
Theodore=0A=
=0A=
> [1]: https://externals.io/message/111218#111254=0A=
> [2]: https://wiki.php.net/rfc#declined=0A=
> [3]: https://externals.io/message/110640#110819=0A=
> [4]: https://externals.io/message/111101#111101=0A=
> [5]: https://externals.io/message/111101#111132=