Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111335
To: Theodore Brown <theodorejb@outlook.com>, Derick Rethans <derick@php.net>,
	PHP Developers Mailing List <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Thread-Index: AQHWamWPHsqLR0j+3kKp37krfiTdR6koJhuAgACfJ78=
Date: Wed, 5 Aug 2020 02:27:24 +0000
Message-ID:
 <DM6PR07MB661896976DF49A1756B3D5D3F94B0@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>,<BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To:
 <BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [KDR45XPQnM9PW48CLusUmvt7Yl44lYv51JLJEJ1opa0r90ccqTV2U/ElrscgbUAL]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 0ef2b7b0-717a-49a4-c94f-08d838e7169e
x-ms-exchange-slblob-mailprops:
 mBRmoEB1kyJBQs/TDT5JAwcVfYFmbbDGQbtM3HVAzBw5OQVPNFMU16hbZk5NH3DSLhtFEtgZnrpVx543yMWOo4t/JYpX5F6KLDLzVb+XcJzHGOoQeJYWydjB49jK/9Al/cZXHlTw/F8ztlMupC0nr2pfzwPgeakYNwXdishmaHyeiK9LPwMELYIfocDiSdaIWkUG5dEuTHEp7uAYW0P5DFkFreVlGvN+DJYVjdnV/T7SlAfOCNNViOpAAW/kT2EWhduKlHV15f43ndc47Ril5FpD0/ROCYS0iN34XspzZSGfyEIQ0i5G97hqhuXy3/+dguXWk8jwK7366n9VUKDGdyTboeJbHSbZhqAM3/lweQsEcBOTakcUDnCo1vETvD44DL8COevsJWvn/HVzUE9szu+ancPUBB6evj5ksxq7khUqBXw8VX84McvBKOLFRNgp6XBfxmD5RqJHyed60YLgejItR2N4KiqVN1TMWMDqmCt/52l4/LAWLUHmU0bFWAzuatfKQ7vbpsfnw05Z3ZXCNd6aZGkvlvX01ZkAUXuR1bv+1o9KoDfe71LvjEzeOmWGCVyyEjcS0QYIRbF53ySunPGI08b8pZNrh62RG9tTYGsAFwJ/0JepAc2ZhgiUt5Etd9M/APheYt557GMBtqOie3pgzbBPlQHUvKb4WjwQqlBMPJa7WT4lpKlqlspV4DWvNZZt4BwpHSUuL4PKtAXB8J28AsOtt2iBLWdtrk9KIAPpswoR8fgjDZWV8CN71jt/20KLrVrHql4=
x-ms-traffictypediagnostic: MW2NAM12HT145:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 fRf4k/2Afph7rbHrztyzWg7mJ1wdBCZv9RuzcJxFxUYVy8hk7s19/TZgEajhlHCSwECUianYAr8lQ+JR0lPoagtt0tQkojkWVZRLDBElQbi0ooEBWmAelFNQgp34UAfjOURid5KPZ5aWNcWMnwYtEjCIctq1QjWnw3CFqb5cjkzbfNXcZeT1Cl3rlcwIZgbAEKjE7q8S3Jccfz5UBLHBIw==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR07MB6618.namprd07.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 /qxLkHKQVmZ2O2cCcWFv+A57sv+IbznWii9r+P3e4x9zE+tW6Yn8PerRPWPSthLf9+LLe/24339slLHE9iHeAj7eT5ox1MbP2nymWhkHqmqlwB81nYjMIgDQk4vx5ueR9bFloZgJka192sauulKSXzCxXXDbsThssWust9m9bCRWUBCfYWp09Gy48ybm6moLYk9jgBdnOBEjg9fDc8V/bQ==
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: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT012.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ef2b7b0-717a-49a4-c94f-08d838e7169e
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 02:27:24.0081
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM12HT145
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: tysonandre775@hotmail.com (tyson andre)

Hi Derick,=0A=
=0A=
> Hi Derick,=0A=
>=0A=
> I don't agree with the main argument put forward in this RFC:=0A=
>=0A=
> > The main concern is that @@ has no ending symbol and it's=0A=
> > inconsistent with the language that it would be the only=0A=
> > declaration or statement in the whole language that has no ending=0A=
> > termination symbol.=0A=
>=0A=
> Attributes are not a standalone statement or declaration; they are=0A=
> metadata *on* a declaration. They cannot stand alone, but always=0A=
> modify the following declaration, just as public and static modify=0A=
> a method, or a type declaration modifies a parameter or property.=0A=
>=0A=
> Modifying declarations (e.g. for visibility and type) do not have an=0A=
> ending symbol. For example, we don't write something like:=0A=
>=0A=
> =A0=A0=A0 [public] function foo([int] $bar) {}=0A=
>=0A=
> With the @@ syntax attributes a treated consistently with type and=0A=
> visibility declarations:=0A=
>=0A=
> =A0=A0=A0 @@Jit=0A=
> =A0=A0=A0 public function foo(@@Deprecated int $bar) {}=0A=
>=0A=
> So there is nothing inconsistent about not having a termination=0A=
> symbol - this is in harmony with visibility and type declarations in=0A=
> PHP, as well as the attribute syntax used by a majority of C family=0A=
> languages. [1]=0A=
>=0A=
> When it comes to supporting attribute grouping, I actually consider=0A=
> this a downside of the #[], @[], and <<>> syntaxes. It complicates=0A=
> the internal implementation, and makes it so developers have to=0A=
> choose between two different syntaxes when adding more than one=0A=
> attribute. In real-world use cases the @@ syntax is just as or even=0A=
> more concise without the extra parser/compiler complexity:=0A=
>=0A=
> =A0=A0=A0 #[Attr1, Attr2] # 15 chars=0A=
>=0A=
> =A0=A0=A0 @@Attr1 @@Attr2 # 15 chars=0A=
>=0A=
> =A0=A0=A0 # 4 lines, 53 chars not counting whitespace=0A=
> =A0=A0=A0 @[=0A=
> =A0=A0=A0=A0=A0=A0=A0 AttrWithParam("foobar"),=0A=
> =A0=A0=A0=A0=A0=A0=A0 SomeOtherAttr("fizzbuzz"),=0A=
> =A0=A0=A0 ]=0A=
>=0A=
> =A0=A0=A0 # 2 lines, 52 chars=0A=
> =A0=A0=A0 @@AttrWithParam("foobar")=0A=
> =A0=A0=A0 @@SomeOtherAttr("fizzbuzz")=0A=
>=0A=
> I agree that we want the best syntax, not necessarily the best=0A=
> **looking** syntax. I still believe that the @@ syntax offers the best=0A=
> balance here. It's familiar, concise without additional complexity,=0A=
> and doesn't break useful syntax the way @[] and #[] do.=0A=
>=0A=
> Kind regards,=A0=0A=
> Theodore=0A=
=0A=
I agree with Theodore's points, including that this is metadata on a declar=
ation, not a declaration itself.=0A=
=0A=
This RFC has proposed that the lack of a closing delimiter might get in the=
 way of future language changes,=0A=
but has not given examples of hypothetical syntax extensions that would cau=
se future conflict=0A=
and that it'd be impossible to resolve/avoid the ambiguity.=0A=
(e.g. Java has managed with `@AttributeName` and optional arguments in para=
meters, classes, properties, methods, etc.)=0A=
=0A=
PHP already has a lot of places where there is no closing delimiter, even w=
here you'd want/expect one,=0A=
so I wouldn't call a lack of closing delimiter unique.=0A=
e.g. the below example is parsed as `clone((new stdClass())->foo)`,=0A=
because parenthesis aren't part of `clone`.=0A=
=0A=
```=0A=
php > clone(new stdClass())->foo;=0A=
Notice: Undefined property: stdClass::$foo in php shell code on line 1=0A=
Warning: Uncaught Error: __clone method called on non-object in php shell c=
ode:1=0A=
```=0A=
=0A=
Thanks,=0A=
- Tyson=0A=