Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111584
To: Benjamin Eberlei <kontakt@beberlei.de>
CC: 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: AQHWamWKUBRwNDrYsUOzfoBQKi8o6Kk6jJOAgAEDLLaAALqdAIAADgONgAAfNXw=
Date: Mon, 17 Aug 2020 15:14:51 +0000
Message-ID:
 <BYAPR05MB653590CAEA7951DC405FFE99DE5F0@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
 <BYAPR05MB65352E2180151559DDFA1E91DE5F0@BYAPR05MB6535.namprd05.prod.outlook.com>,<CAEPJdunPh1JudU6-_+v=4a9jpha289GWqcOdbvDtHySJJsnYhg@mail.gmail.com>,<BYAPR05MB6535279E02E661942533BAD3DE5F0@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To:
 <BYAPR05MB6535279E02E661942533BAD3DE5F0@BYAPR05MB6535.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [rEkTw+2GfEz3w2AajD24lDLwgzKbeXxQ]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 24ed0a33-3eb4-4c29-9520-08d842c04a06
x-ms-traffictypediagnostic: BN3NAM04HT177:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 9m0Vb5T+l+BTpo2SRTOXxNO2Efjt7fo7YKSO3bCwzL9GeocQjgHA5mCmbxDNjpvhBVGkxIy1XJoLN8bycPCFB04pzNRcOdDB/Hp4FJUL5G5Xe9buIJTiZOGjjXkEstmJbSF01JyT/MXJADVuL9v33qcNvUjEm1fpXvi9mnj6QDMyFMXlhjiF7+Tb9dIHHqYhdJMZJx6QabHQgk6FiN8bsw==
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;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 pAbHkr/Sa72SbuYavw0OeRRzctexHkP/G5OOiz5D3kQzjASscF/307ZkAYWsP8VWf0P6iOuISacNG8QEjUX4ucqbw/wOFJN6sBw8ZwbECUpU6QBqpCGCaa5teZUyCgdi6ul5g1cVVv2Dgp7N83cO4Q==
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: BN3NAM04FT013.eop-NAM04.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 24ed0a33-3eb4-4c29-9520-08d842c04a06
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 15:14:51.5454
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT177
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: theodorejb@outlook.com (Theodore Brown)

On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown <theodorejb@outlook.com> wro=
te:=0A=
=0A=
> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei <kontakt@beberlei.de> wr=
ote:=0A=
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown <theodorejb@outlook.com>=
 wrote:=0A=
> > > ## Potential Future Benefits of Enclosed Delimiter Syntax?=0A=
> > >=0A=
> > > The RFC shows an example of a potential "simpler" attribute using a=
=0A=
> > > string instead of a class name. I honestly have no idea what this is=
=0A=
> > > supposed to do or what benefit it would have over normal attributes.=
=0A=
> > >=0A=
> > > The concept of attributes being a class name with optional arguments=
=0A=
> > > has been proven over many years by its use in docblock annotations,=
=0A=
> > > and if there was some deficiency in what this syntax allows it seems=
=0A=
> > > like we would have discovered it by now.=0A=
> >=0A=
> > I agree on just the string, but a closure would make 100% sense for=0A=
> > a decorating feature. Javascript and Python "Attributes" work as=0A=
> > decorators, i.e. they get called around the decorated function.=0A=
> >=0A=
> > It is not a completely unrealistic feature to think off:=0A=
> >=0A=
> > @[fn($x) =3D> syslog(LOG_INFO, "Called function foo with x: " . $x)]=0A=
> > function foo($message) {}=0A=
> =0A=
> As I understand it JavaScript decorators do not use anonymous=0A=
> functions for decorators like this, though. Instead you would make a=0A=
> named function and apply it with `@myFunc()` before the decorated=0A=
> function or class.=0A=
> =0A=
> Presumably we could accomplish the same thing in PHP with e.g. an=0A=
> `__invoke` method in the attribute class, without complicating the=0A=
> attribute syntax itself.=0A=
=0A=
One other thought on this. I agree that decorators are not a=0A=
completely unrealistic future feature. However, it must be noted that=0A=
both JavaScript and Python use the `@Attr` syntax for decorators, and=0A=
the lack of an end delimiter in no way precludes this usage.=0A=
=0A=
The whole point of a decorator is to offer syntax sugar for a common=0A=
reusable pattern (pass a function/class to another function which can=0A=
add additional information or behavior to it). It's not clear how an=0A=
anonymous closure would be useful for this, since it would not allow=0A=
reusability, which defeats the purpose.=0A=
=0A=
So the argument that an end delimiter has "potential future benefits"=0A=
still lacks any realistic examples, and is countered by years of=0A=
proven usage of the `@Attr` syntax in docblocks and other languages.=0A=
=0A=
Sincerely,  =0A=
Theodore=