Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109695
To: Benjamin Eberlei <kontakt@beberlei.de>, PHP Internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: [RFC] Attributes v2
Thread-Index: AQHWFKX7h7lS/adMzU6pjZVUKKg53ah9ej1D
Date: Fri, 17 Apr 2020 16:11:28 +0000
Message-ID:
 <BYAPR05MB6535096AE763314D929B722ADED90@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <CAEPJdunSr8PkBtSLO8g_JMLzM4cFVnXsQSEMFmu2RN25XT=grw@mail.gmail.com>,<CAEPJdumeStFzWRcEtU3NjEgmxZ_08wbfyJezhHOEzZbzdNWC=w@mail.gmail.com>
In-Reply-To:
 <CAEPJdumeStFzWRcEtU3NjEgmxZ_08wbfyJezhHOEzZbzdNWC=w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [4IByFltFDuC0w7+Kj4Coy3KuB1OI/DYP]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: de492865-413e-47a3-8157-08d7e2e9fc8b
x-ms-traffictypediagnostic: CO1NAM04HT233:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 kI/9IJUCjklAcFLfWPePD4Nus8jhvP8NF0KPUnK6FiUtWX9quOSHexd18+g6mJsf/02nmn4UqCeyDbdjfo+LFgElBrVbhX2wK8/hAvpfJjUS81TX43P0iEF386W/uiqUF71LvUgw4DRgZGKyhOTqQziP1zYhAXnyTcqnLrtWAW7MeV+8CXM6tP3zIqZOhTIU2Htbjdoekm5OAU0VNEfE4kXuZ/jkOq0hwYqO/RH4ypnPC38RiOf3M1MhnbIbZv51
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:
 fF7a0mMRRraKWMmuVTTx2L9f/q9uMcEe4Q1WCXFvW1oyYpISQVfMebZCvL+LYBQG/FaE5N/Wpn03tDUcJx/l37Z2eCxWV6tN5LNCsAhlRnpSUxV/WzJZneAyZezjGOKFkhhfVFYhPkPMUMGby7Makw==
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-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: de492865-413e-47a3-8157-08d7e2e9fc8b
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2020 16:11:28.7453
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT233
Subject: Re: [PHP-DEV] Re: [RFC] Attributes v2
From: theodorejb@outlook.com (Theodore Brown)

On Fri, Apr 17, 2020 at 5:49 AM Benjamin Eberlei <kontakt@beberlei.de> wrot=
e:=0A=
=0A=
> As there has only been minimal new discussion after the last changes to t=
he=0A=
> RFC I wanted to give a heads up that I will open the vote on Monday=0A=
> afternoon.=0A=
> =0A=
> If you have further remarks or questions about the RFC, please let me kno=
w.=0A=
> =0A=
> On Mon, Mar 9, 2020 at 3:42 PM Benjamin Eberlei <kontakt@beberlei.de> wro=
te:=0A=
> =0A=
> > Hi all,=0A=
> >=0A=
> > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in=
=0A=
> > 2016 with a few changes, incorporating feedback from the mailing list b=
ack=0A=
> > then and from talking to previous no voters.=0A=
> >=0A=
> > The RFC is at https://wiki.php.net/rfc/attributes_v2=0A=
=0A=
Hi Benjamin,=0A=
=0A=
Thanks for working on this RFC. I have a couple questions and=0A=
thoughts about the proposed syntax options.=0A=
=0A=
First, the RFC says that the alternate T_ATTRIBUTE `@:` token has the=0A=
downside "that it does not permit whitespace in attribute names to=0A=
allow detecting the ending of the declaration." Can you provide an=0A=
example of an attribute name containing whitespace that would be allowed=0A=
with the shift left/right tokens but not with the attribute token?=0A=
=0A=
The RFC says that "Semantically the attribute declaration should be=0A=
read as instantiating a class with the attribute name and passing=0A=
arguments to the constructor." But class names can't contain spaces,=0A=
so how is it a downside for attribute names to not permit them either?=0A=
It seems like it would be a massive footgun to allow attribute names=0A=
that *can't* resolve to a class name, since there would be no way to=0A=
migrate them to a declared attribute class without a BC break. For this=0A=
reason, regardless of the final syntax choice I think whitespace should=0A=
not be permitted in attribute names.=0A=
=0A=
Secondly, given that attribute arguments are evaluated as constant=0A=
expressions, it's far easier for me to read the T_ATTRIBUTE `@:` syntax=0A=
at a glance than the syntax reusing shift left/right tokens. With the=0A=
latter my eyes tend to confuse shift left/right tokens in a constant=0A=
expression with the open/close token of an attribute (especially since=0A=
the syntax using bit shift tokens allows multiple attribute declarations=0A=
on the same line).=0A=
=0A=
Consider this example using the shift left/right token syntax:=0A=
=0A=
```php=0A=
<<BitShiftExample(4 >> 1, 4 << 1)>><<OtherAttribute(4 >> 1, 4 << 1)>>=0A=
function foo() {}=0A=
```=0A=
=0A=
To me the same thing using the T_ATTRIBUTE syntax is far more readable:=0A=
=0A=
```php=0A=
@:BitShiftExample(4 >> 1, 4 << 1)=0A=
@:OtherAttribute(4 >> 1, 4 << 1)=0A=
function foo() {}=0A=
```=0A=
=0A=
Best regards,=0A=
Theodore=0A=