Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111364
To: Benas IML <benas.molis.iml@gmail.com>
CC: 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+AgAAJNoCAABvtAIAAbz82gAAHqACAAFtL4w==
Date: Fri, 7 Aug 2020 00:23:40 +0000
Message-ID:
 <BYAPR05MB6535BD371D9084AF7C16A9B6DE480@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>
In-Reply-To:
 <CANeKSiSFJPmrtLcuxtPh7Sov21JNJTe3SMrS4WzJa_ZCVkcViw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [t09StNT5+V/uTYpzqqjXOwZ9eqwuWNe9]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 0bac9aab-c278-419f-8054-08d83a6822c4
x-ms-traffictypediagnostic: DM3NAM02HT033:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 dNWWVEq5nQry3IzlD0XGD5P7hof0IybHKRLejBXUdWhIug8JYlXSHFgOOFkTPlS3wv2JkPe+8n4FlMvYNsx9cvHFf+rj7OKHXoamRHgKRNAwxQoK8CJeYWUUtpmrBbxmZLz7c/N6cT0qK/XbiR9+9Kibb1c7m0Mu0eqgvXLpOGmCLWe6RK2+eXXBN2SBne9rnWiTWlQ9gb0e+CQRhzze1g==
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:
 5FGmPIm+WKx7esajB1lLz1cEOsIR7PGrUQSwyX2R9tXlzeJDOXSpxNvtKI5FuYBSnh5SvqCBtOp0Kj2SlBwf/hf4bj+7eOObMuPTRwMswFrmuzH0dJuUecdtPeZ1m9J6ArEjw1cBgnwtDFqb/5YNaQ==
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: DM3NAM02FT053.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0bac9aab-c278-419f-8054-08d83a6822c4
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 00:23:40.6818
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM02HT033
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: theodorejb@outlook.com (Theodore Brown)

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> wrot=
e:=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=
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=
- Adding or removing a second attribute with grouping can require=0A=
modifying multiple lines, adding unnecessary noise to diffs:=0A=
=0A=
      @@SomeAttribute("value")=0A=
      @@AnotherAttribute("value") # can be added/removed independently=0A=
      function foo() {}=0A=
=0A=
      # vs.=0A=
=0A=
      @[SomeAttribute("value")] # changes to:=0A=
=0A=
      @[=0A=
          SomeAttribute("value"),=0A=
          AnotherAttribute("value"), # not added/removed independently=0A=
      ]=0A=
      function foo() {}=0A=
=0A=
- How much more added complexity will the grouped syntax require if=0A=
we add nested attributes in the future? At the least it will have to=0A=
be special-cased in some way, either to disallow grouping for nested=0A=
attributes or to treat the grouped syntax the same as an array.=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=
> > - It is aligned with the attribute semantics of the majority of C=0A=
> > family languages=0A=
>=0A=
> In what way `#[]` or `@[]` aren't?=0A=
=0A=
The majority of C family languages use `@Attr` without an extra end=0A=
symbol. This makes sense since attributes are simply metadata=0A=
modifying the declaration that follows them, similar to visibility=0A=
and type declarations.=0A=
=0A=
Best regards,  =0A=
Theodore=