Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111368
To: Benjamin Eberlei <kontakt@beberlei.de>
CC: Benas IML <benas.molis.iml@gmail.com>, Rowan Tommins
	<rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Thread-Index:
 AQHWamWKUBRwNDrYsUOzfoBQKi8o6KkoJexGgAKAW4CAAAhPgIAADw+AgAAJNoCAABvtAIAAbz82gAAHqACAAFtL44AAoLyAgABE5mU=
Date: Fri, 7 Aug 2020 12:41:29 +0000
Message-ID:
 <BYAPR05MB653568CD28BDC009D7D1C48EDE490@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>
 <alpine.DEB.2.23.453.2008060741110.7489@singlemalt.home.derickrethans.nl>
 <20200806091749.64675445@mcmic-probook.opensides.be>
 <CANeKSiStbGZG+EOVDRfRuVo4MA7th16R-oP7V2xmPj3xHNxs_A@mail.gmail.com>
 <CALKiJKporEo8DitTBqom=u0onqwQU+MiWF45R61cGHXzU783Fw@mail.gmail.com>
 <CANeKSiRivtUWsH8ySYVtjmz3JX8mrs-OJLEin_2V+A7xt18X+A@mail.gmail.com>
 <BYAPR05MB65357345667E6A35EDD89025DE480@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CANeKSiSFJPmrtLcuxtPh7Sov21JNJTe3SMrS4WzJa_ZCVkcViw@mail.gmail.com>
 <BYAPR05MB6535BD371D9084AF7C16A9B6DE480@BYAPR05MB6535.namprd05.prod.outlook.com>,<CAEPJdu=f8q_igN5LNGvOhnyPwNvCazqfsehZ6Dg6g40pWu_J_g@mail.gmail.com>
In-Reply-To:
 <CAEPJdu=f8q_igN5LNGvOhnyPwNvCazqfsehZ6Dg6g40pWu_J_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [JhAPqPBVBGmnTdxf29uxyPqX1HG4a2/8]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: b239158d-f57f-492e-cb36-08d83acf3552
x-ms-traffictypediagnostic: MW2NAM10HT139:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 cbC96ZJy5DLdHdIuxELJZiDIgKH4Vkj36OrcVP5aT0dP9+HPapsGxd4bI3tyB22V0e0ClJe4U12xosYYpMrpURmxhXHjymbIb/aFsJzFd7UEcS8tw0+fcTkTgIrn9h/nsTZDmVAIyk00ybeb/X58VSnt8uYa0qkIXRn3EkXQuPRsylK7UbZKaTbjUo8QLDCdZJAHJEEPjV9AC6SILMoRIcyHdzxJW2vjB3kvj6+Je2GG9xT/3B5pf8/q9fkowkte
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;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 QXqQHTD/1+lbyzmr1fKZIyTgnbYb21+jKIfaSIms1LtSdpWGxl3MHPeL0aJ67NYxJZ3ndeveEVtmm+qwDeiFu9guAxdKAub9NrzsPxbNNDe192FQ/FMisVcelxZcOGSR1y3HpwrBQ5OFG+W20fs65g==
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: MW2NAM10FT051.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: b239158d-f57f-492e-cb36-08d83acf3552
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 12:41:29.9615
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM10HT139
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: theodorejb@outlook.com (Theodore Brown)

On Fri, Aug 7, 2020 at 3:32 AM Benjamin Eberlei <kontakt@beberlei.de> wrote=
:=0A=
=0A=
> On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown <theodorejb@outlook.com> wr=
ote:=0A=
> > On Thu, Aug 6, 2020 at 12:30 PM Benas IML <benas.molis.iml@gmail.com> >=
 wrote:=0A=
> > =0A=
> > > Hey Theodore,=0A=
> > >=0A=
> > > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown <theodorejb@outlook.com> =
> wrote:=0A=
> > >=0A=
> > > > While none of our syntax options are perfect, I believe @@ has the=
=0A=
> > > > best long-term tradeoffs because:=0A=
> > > >=0A=
> > > > - It doesn't break useful syntax=0A=
> > >=0A=
> > > Fair enough.=0A=
> > >=0A=
> > > > - It is equally or more concise than grouped attributes without=0A=
> > > > adding complexity to the parser/compiler=0A=
> > >=0A=
> > > Are we really going to debate that ~30 lines of code add complexity?=
=0A=
> > =0A=
> > Hi Benas,=0A=
> > =0A=
> > I don't know how many lines of code it will be, since an=0A=
> > implementation for it has never been finished. The patch currently=0A=
> > linked in the RFC does not implement it.=0A=
> =0A=
> Curious what brings you to claim an implementation has never been=0A=
> finished when it was accepted by RFC vote?=0A=
> =0A=
> Grouping certainly has a finished implementation, Martin and I had it=0A=
> working for the original RFC, then when we removed it for the original=0A=
> vote had a working patch and PR as part of the Amendments RFC.=0A=
=0A=
Hi Benjamin,=0A=
=0A=
Apologies, I didn't realize the grouped attribute implementation was=0A=
completely finished before. When it was dropped from the Attribute=0A=
Amendments pull request, a bunch of other changes still had to be=0A=
made before it was ready to merge, and I assumed that some changes=0A=
would have also been required for attribute grouping. Thank you for=0A=
the correction.=0A=
=0A=
> I now ported the patch to the @[] syntax PR here: [updated link]=0A=
> https://github.com/php/php-src/pull/5928/commits/597688fd5b0a41d23028454b=
62ba25f950f35a16=0A=
> The zend_compile.c diff looks a bit complex, but it's really only 5=0A=
> new lines for a new for loop over the groups and all existing code=0A=
> one level deeper.=0A=
> =0A=
> All in all the attribute grouping patch adds 26 new lines (and then=0A=
> tests) all restricted within the existing attribute parser rules and=0A=
> the functions compiling attribute code. This adds no complexity at all.=
=0A=
=0A=
This is some new complexity, even if only a small amount right now.=0A=
My question remains about how much more added complexity it will=0A=
require later if we implement extensions like nested attributes.=0A=
=0A=
> > Even if we assume the implementation is only about 30 lines, it's=0A=
> > still extra complexity that I don't understand the benefit of. I=0A=
> > sincerely would like to know what advantage there is of grouped=0A=
> > attributes over the `@@` syntax.=0A=
> > =0A=
> > - It is equally or more verbose than `@@` in real-world use cases=0A=
> =0A=
> You keep bringing up verbosity like our primary language design goal=0A=
> is to reduce it, PHP is the most verbose language I know. Everything=0A=
> in PHP requires more characters than in other languages. Keywords are=0A=
> usually long, variables need an extra $ in front. You have to use=0A=
> $this-> as no implicit context exists. Functions need to be prefixed=0A=
> by "array_", "str_" instead of methods on the objects.=0A=
=0A=
Yes, PHP has historically been rather verbose in some ways.=0A=
Thankfully this has been gradually changing, with the short array=0A=
syntax added in 5.4, and more recently short arrow functions,=0A=
constructor property promotion, and the match expression having an=0A=
explicit goal to reduce verbosity.=0A=
=0A=
> The primary design goal of a language construct in PHP is not to=0A=
> reduce verbosity.=0A=
=0A=
What is the goal of the grouped attribute construct? I still haven't=0A=
received an answer about what makes it better than `@@`.=0A=
=0A=
> > `@@` avoids the need for additional complexity, special cased syntax,=
=0A=
> > and having to modify extra lines when adding/removing separate=0A=
> > attributes.=0A=
> >=0A=
> > > > - It is conceptually closest to the docblock syntax the PHP=0A=
> > > > community is familiar with=0A=
> > >=0A=
> > > Well, if `@@` is similar to `@` (to me it isn't), we can say that=0A=
> > > `@[]` is also similar to `@`.=0A=
> > =0A=
> > I would agree that `@[]` is more similar than `#[]` is. But arguably=0A=
> > `@@` is still the closest since docblock annotations don't require=0A=
> > being wrapped in array brackets.=0A=
> =0A=
> But docblocks are wrapped in /** */, enclosing the whole declaration=0A=
> of them.=0A=
> =0A=
> Both @[] and #[] are comparable with /** */ as metadata **boundary**.=0A=
> The attribute itself has no symbol prefixes or alike, it's just the=0A=
> class name.=0A=
> =0A=
> This is a very close translation to how docblocks with userland=0A=
> doc-params work, in my opinion this makes all enclosed syntaxes much=0A=
> more in line with existing syntax, regardless of symbols used.=0A=
=0A=
Aren't docblock annotations only wrapped in /** */ because they have to=0A=
be inside a comment? There is no need for this with the native=0A=
attribute syntax. To me, the `#[]` and `@[]` tokens don't at all look=0A=
similar to docblock comment boundaries, anyway.=0A=
=0A=
Best regards,  =0A=
Theodore=