Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111518
To: Benjamin Eberlei <kontakt@beberlei.de>
CC: Derick Rethans <derick@php.net>, "internals@lists.php.net"
	<internals@lists.php.net>, Sara Golemon <pollita@php.net>
Thread-Topic: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
Thread-Index:
 AQHWbvIBydbCX+rhJUWK/r8c7hnlt6k0kNaHgAALBwCAAAp7tYABDvUAgABUQtmAAAkjgIAAH1r+gAB81YCAACtXAIAApHfEgAAuaYCAABthug==
Date: Fri, 14 Aug 2020 15:58:22 +0000
Message-ID:
 <BYAPR05MB6535CEFB9DEF0652D51AEE35DE400@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>
 <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>,<CAEPJdukoJR_dmYehaiWO_7XTCOnOvuDYtKpPWQSV+V+yhNGfhA@mail.gmail.com>
In-Reply-To:
 <CAEPJdukoJR_dmYehaiWO_7XTCOnOvuDYtKpPWQSV+V+yhNGfhA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [wqyOHdu75rmsJdX4K2mvAYn6/KnWo8ar]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: c4dacc3f-580d-471f-afbb-08d8406adf08
x-ms-traffictypediagnostic: BN7NAM10HT221:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 u7TiW/cSwDwi5Z3AFtoVP9MGLhPVZmFSIJeEA4Ff1jbpSBAg8rDcOP9qokdB284BNs63w27rueGaOqFwY6Vj5MjFPcup3+sv18LmCdLNyRYyWOz+b0vBLrCRp6uWaJF6g/WTEXs+KBPo4gIFegxdJj3+K9T/SHj7C97iupWQI/iaxE4uWM/CZJZpMvtFtaV6aHPCP8ezgD23Dw52W8s5OpyxlA2tmaki7wnwBXRUcg7SKk6S4rumBSdYcdpQDbtU
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:
 /Brq0Lq6f6q0/Tk/QnvXugy6RDHsvc8h3Ot1DSGTPioUlKMbVvvtbcEMvXf+IEfN8Q7rBW1SW6MrjmlwdQUvYB6WDxO7tanlAEyZptNvFy0f4pUmLqhnNvNU2Xp51nlESPRB0tLr9u1nbVKlxaFVxQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: BN7NAM10FT006.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: c4dacc3f-580d-471f-afbb-08d8406adf08
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 15:58:22.4954
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7NAM10HT221
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: theodorejb@outlook.com (Theodore Brown)

On Fri, Aug 14, 2020 at 9:16 AM Benjamin Eberlei <kontakt@beberlei.de> wrot=
e:=0A=
=0A=
> On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown <theodorejb@outlook.com> w=
rote:=0A=
> > There's certainly been a lot of discussion in general about=0A=
> > attributes. However, there was not a reasonable opportunity to either=
=0A=
> > discuss the specific arguments made in this RFC (e.g. the lack of a=0A=
> > closing symbol being inconsistent), or submit patches for alternative=
=0A=
> > syntaxes as Derick requested when he put up the RFC for discussion.=0A=
> > =0A=
> > I was very surprised that it went to vote less than six days after=0A=
> > the discussion period started, right after the weekend no less,=0A=
> > before I had a chance to submit my patch to include the @: syntax.=0A=
> > =0A=
> > I'm as weary of the discussion as anyone, and would like to see=0A=
> > closure on this topic sooner rather than later. But if the voting=0A=
> > rules aren't followed, how can the vote result be considered=0A=
> > legitimate or binding?=0A=
> > =0A=
> > If the authors sincerely want the best outcome for the language (and=0A=
> > I assume they do), what harm is there in deferring the vote until the=
=0A=
> > discussion period has completed, and ensuring that the RFC addresses=0A=
> > the arguments on both sides and contains all the relevant information=
=0A=
> > for making a decision? Otherwise many contributors (myself included)=0A=
> > just end up feeling unheard, unhappy, and unconfident that the right=0A=
> > choice is being made.=0A=
> > =0A=
> > With this in mind, I'd like to respectfully make the following=0A=
> > requests:=0A=
> > =0A=
> > 1. Defer voting until the two week discussion period is complete=0A=
> > (Tuesday, August 18).=0A=
> =0A=
> What do you mean by defer exactly? Stop voting or reset the vote?=0A=
> We were thinking of extending the vote until September 1st.=0A=
=0A=
Hi Benjamin,=0A=
=0A=
Yes, my request is to stop/reset the vote until after the discussion=0A=
period is complete. Otherwise few people will see the updates made to=0A=
the RFC since they already voted.=0A=
=0A=
> > 2. Include a ranked voting option for @: and mention its pros and=0A=
> > cons (it is equally concise as @@ with no BC break, but is somewhat=0A=
> > harder to type). Patch link: https://github.com/theodorejb/php-src/pull=
/1=0A=
> =0A=
> I am wondering where @: is suddenly coming from? It wasn't discussed=0A=
> in both shorter attributes RFC and the discussion leading to this RFC.=0A=
=0A=
@: wasn't included in the Shorter Attribute Syntax RFC because I=0A=
didn't realize it was allowed to re-vote on a failed secondary poll=0A=
after less than six months. However, since we're re-voting on #[] I=0A=
think it's only fair to include @: as well - some people may prefer a=0A=
short syntax but dislike the specific look of @@. Personally I would=0A=
like to vote for @@ as my first preference and @: as my second.=0A=
=0A=
> There were a few other suggestions like $() or "using attribute", but=0A=
> none of them was followed up upon. Nobody replied to my or Dericks=0A=
> message with a specific interest in actually contributing another patch,=
=0A=
> including @:=0A=
=0A=
I hadn't replied to this part of Derick's message yet because the=0A=
voting started before I had a chance to write the patch.=0A=
=0A=
> > 3. Add a Backward Incompatible Changes section with examples of the=0A=
> > code that the different syntax options would break.=0A=
> =0A=
> Derick and I are working on this section to update the RFC later today.=
=0A=
> We didn't consider this relevant, because the mitigation steps for all=0A=
> of them is the same: a project wide search and replace to insert a space=
=0A=
=0A=
Thank you for working on this. The mitigation for current usages of=0A=
@@ should be to delete the extra symbol rather than adding a space=0A=
(though I'm very doubtful that any usages of @@ even exist currently,=0A=
since extra suppression operators don't do anything useful).=0A=
=0A=
The main benefit of the BC break section will be to highlight examples=0A=
of how @[] and #[] break syntax that is both valid and useful, while=0A=
@@ does not.=0A=
=0A=
> > 4. Add a Discussion section briefly summarizing the arguments that=0A=
> > have come up on list. In particular this should include:=0A=
> >    a) Tyson's examples of #[] changing the meaning of code in=0A=
> >       unexpected ways between PHP 7 and 8 (e.g. a parameter=0A=
> >       attribute would remove the parameter when run on PHP 7).=0A=
> =0A=
> This is also included in the update, but ultimately is covered by the=0A=
> explanation for "Forward Compatibility" already mentioning that it=0A=
> does only work with a subset (and hence does not work for some other=0A=
> subset).=0A=
=0A=
Okay, but I think examples are necessarily to illustrate which subset=0A=
of the new syntax works and what does not. It certainly wasn't clear=0A=
to me before I saw Tyson's examples.=0A=
=0A=
> >    b) An example of the downside of grouping, where it causes=0A=
> >       unnecessary diff noise when adding or removing a second=0A=
> >       attribute on its own line.=0A=
> =0A=
> This is a problem for coding styles to solve and is nothing the RFC=0A=
> should be concerned with. Grouped syntax specifically includes support=0A=
> [for] trailing commas. Diff noise is something all declarations with=0A=
> optional elements can cause, even use of @@ in one line can be "forced"=
=0A=
> from single to multi lines creating diff noise under reasonable Coding=0A=
> Standard assumptions.=0A=
=0A=
Even if you "force" an attribute with @@ across multiple lines, that=0A=
individual attribute can still be added/removed without modifying the=0A=
attributes on other lines.=0A=
=0A=
On the other hand, with grouping the only way to avoid modifying=0A=
extra lines when adding/removing a second attribute would be to=0A=
mandate that the first attribute always be written like this:=0A=
=0A=
    #[=0A=
        SomeAttribute,=0A=
    ]=0A=
    function foo() {}=0A=
=0A=
But this also makes diffs noisier since at the very start two extra=0A=
lines have to be included.=0A=
=0A=
Best regards,  =0A=
Theodore=