Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111237
To: Mark Randall <marandall@php.net>, "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Thread-Index: AQHWZO4EZIMJMorBK0qxy5SLq6JXCakdN4bOgAAr8wCAACScWg==
Date: Tue, 28 Jul 2020 21:55:11 +0000
Message-ID:
 <BYAPR05MB65352C42F9A050AAE405D866DE730@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
 <BYAPR05MB6535E638D874FB9D6653411CDE730@BYAPR05MB6535.namprd05.prod.outlook.com>,<b388d02a-9baa-481e-bf49-3aad1c467880@DB3EUR04FT028.eop-eur04.prod.protection.outlook.com>
In-Reply-To:
 <b388d02a-9baa-481e-bf49-3aad1c467880@DB3EUR04FT028.eop-eur04.prod.protection.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [RO/hbis9E8F/flSe+2e269AjVbHEsTTb]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 6b7e7e5d-cde7-4332-0888-08d83340e68f
x-ms-traffictypediagnostic: DM6NAM11HT003:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 wxw79cAn2nuvONSQfyry/6p/unJQNmRSTyNYcHHo6s0dhx+Zhn/9NhFgZpaJ4wDpNKcCwxSk9lLATzwvOjRDfAMBsvtyT1kgNI8Io+mG1cSiVVWPBGnZG+LYRWJYGFDCKpDJZ5YfBOxkcL3HBygaq55uVbD3pFur4XQXofxmujLN7Or7lR0AUSPCQSeA5nFYnxX9CxwDGKkLFbNxaMs5Bg==
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:
 DPRZpEOaPaCUggdlv8wjsV4tOoAP2d1HOfwAuJBPgrOMhNJY94mqmoooMjenEDXwtVWI3lJB2f5H8J8INWabUyov1onbuHCOQDMOGEfisUG3P/egXhwaadus68obbtPYJRkEUdeDMmruv/BM4DTzug==
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: DM6NAM11FT026.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b7e7e5d-cde7-4332-0888-08d83340e68f
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 21:55:11.0662
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT003
Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
From: theodorejb@outlook.com (Theodore Brown)

On Tue, July 28, 2020 at 2:38 PM Mark Randall <marandall@php.net> wrote:=0A=
=0A=
> On 28/07/2020 18:57, Theodore Brown wrote:=0A=
> >> Having a closing ] makes it easier to extend Attributes with more synt=
ax=0A=
> >=0A=
> > This might be a good argument if there were actually a need to extend=
=0A=
> > attributes with more syntax. What other languages have found a need for=
=0A=
> > this? Even Rust doesn't allow additional syntax inside the brackets.=0A=
> =0A=
> Just because they haven't, does not mean we won't. Unless there's a good=
=0A=
> reason to do otherwise, we should provide for future flexibility where=0A=
> possible.=0A=
> =0A=
> I previously provided examples of ways in which we might want to extend=
=0A=
> the syntax.=0A=
=0A=
Hi Mark,=0A=
=0A=
I appreciate the examples. I think there are good reasons not to=0A=
implement these kind of extensions, at least in this form. I'll reply=0A=
to each example below.=0A=
=0A=
> Most things in PHP allow some level of scope restriction, such as=0A=
> private or protected. One day we may want to extend annotations to=0A=
> include such a feature, such as a protected annotation that can only be=
=0A=
> accessed by the class itself or its descendants.=0A=
> =0A=
> #[protected MyAttribute(xyz)]=0A=
=0A=
Given that attributes are metadata, restricting their scope seems=0A=
rather pointless, and probably would only encourage their (mis)use=0A=
for things they aren't the right solution for. Isn't the whole point=0A=
of an attribute to be read by something outside the class? If the=0A=
metadata is only for the class itself, class constants with=0A=
appropriate visibility can be used instead.=0A=
=0A=
> Attributes are not validated when they are encountered, this may be=0A=
> something that we wish to allow attributes to opt-in to in future.=0A=
> =0A=
> #[checked MyAttribute(xyz])=0A=
=0A=
I hope if we allow opting into such a feature it won't have to be so=0A=
verbose and won't require making checked a new reserved keyword. I=0A=
suppose the same thing could be accomplished with a distinct token,=0A=
for example:=0A=
=0A=
@@!MyAttribute(xyz)=0A=
=0A=
> In future we might want to offer APIs that return an array of all of the=
=0A=
> instances (moving the creation up from newInstance) and then tighten up=
=0A=
> the behvaiour for classes which do not exist (because they might belong=
=0A=
> to an optional package, such as debugging or code analysis). This might=
=0A=
> come in the form of something like:=0A=
> =0A=
> #[optional MyAttribute(xyz)]=0A=
=0A=
Existing attributes are already optional, though, so it's not clear=0A=
what value this would add. If we want some attributes to not be=0A=
optional, we could add a new syntax for checked attributes like the=0A=
previous example.=0A=
=0A=
> Some of these might happen, none of these might happen, something=0A=
> completely different might happen.=0A=
> =0A=
> What is clear is we've got to support Attributes for 20, 30 years, and=0A=
> we should leave the door open for easier and cleaner syntax additions if=
=0A=
> there's no compelling reason not to.=0A=
=0A=
I'm not convinced this approach of additional keywords before an=0A=
attribute is the easiest or cleanest way to implement additions. It=0A=
seems like it could lead to more BC breaks and unnecessary verbosity=0A=
if it encourages adding new keywords. And as you point out, whether=0A=
any such additions happen is completely hypothetical right now.=0A=
=0A=
In the present what we do know is that #[] is a bigger BC break than=0A=
@@, and that other languages haven't had a need for such syntax=0A=
additions in the many years that attributes have been around.=0A=
=0A=
Best regards,  =0A=
Theodore=