Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111581
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: AQHWamWKUBRwNDrYsUOzfoBQKi8o6Kk6jJOAgAEDLLaAALqdAIAADgON
Date: Mon, 17 Aug 2020 13:07:17 +0000
Message-ID:
 <BYAPR05MB6535279E02E661942533BAD3DE5F0@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>
In-Reply-To:
 <CAEPJdunPh1JudU6-_+v=4a9jpha289GWqcOdbvDtHySJJsnYhg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [y0KBD9exRvwRSSrv2/KekFEQgpkUj8ZD]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 53eae3b4-173d-43c1-1cdf-08d842ae77e2
x-ms-traffictypediagnostic: BN8NAM12HT240:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 iBcWJZDABW83cGWD6cjpEJGu5MlyvmdjtnoL+jnqXcGTRaXcs8VEyzg9bB3cq/9A63wJd9SR132AsQjAdhGsWqPMYtnDu6XxfLLfTq8uq6DTTtu2w+AYFCBcOuI+Vy5HuAAioRTKSeQDdFcw/upfGcBlW43eJRhL7uiehxN9piHAtdJR/V5s60wh+4O1WNGdLG5um8teLjiggh9Ze+uKkw==
x-ms-exchange-antispam-messagedata:
 hPHigkDwM/z4ErhAUF1g1In3CQyxKlSiwObQbaHsH/dN61KB4rI18w7zxOsQKDHN11r3aFoEEp5YHZTFG5sOeP36txTarP5jeY/eosJuqdlvWmyOXqxIILMvQIsRtT16fYTbQmoDAwiPxqbDHasHmw==
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: BN8NAM12FT056.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 53eae3b4-173d-43c1-1cdf-08d842ae77e2
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 13:07:17.4775
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM12HT240
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: theodorejb@outlook.com (Theodore Brown)

On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei <kontakt@beberlei.de> wrot=
e:=0A=
=0A=
> On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown <theodorejb@outlook.com> w=
rote:=0A=
> > However, ending delimiters in PHP have little to do with how "complex"=
=0A=
> > a syntax construct is (which is a rather loose definition, anyway).=0A=
> > As I've pointed out before, standalone statements and declarations=0A=
> > generally require an end symbol, but modifiers before a declaration=0A=
> > do not. Attributes fall into the latter category, and therefore the=0A=
> > lack of an end delimiter is consistent.=0A=
> =0A=
> A docblock is also a "modifier" under your declaration and it has an=0A=
> ending symbol.=0A=
=0A=
The difference is that a docblock comment is also a standalone =0A=
declaration - it's quite common to add one at the top of a file=0A=
that doesn't modify any other declaration.=0A=
=0A=
> The RFC gives a definition of the complexity as just a token vs a=0A=
> set of name, arugment_list and constant expression parser rules. It=0A=
> shows an example porting an ORM\JoinTable Attribute, which has=0A=
> arguments, named parameter usage, complex definitions of default=0A=
> values (Strings, arrays).=0A=
>=0A=
> This piece of code probably touches 10-20 parser rules.=0A=
>=0A=
> Most modifiers don't even have a parser rule, as they only match=0A=
> their token.=0A=
=0A=
In this comparison really the only "complex" part of an attribute is=0A=
the argument list, which already has its own start and end delimiters.=0A=
So I don't really see the need to add another end delimiter after the=0A=
argument list end delimiter.=0A=
=0A=
> Types are missing indeed, and they are more complex than a simple=0A=
> token, but less complex than attribute declarations.=0A=
>=0A=
> I guess the difference is that union types are new, and type=0A=
> definitions used to be simple. Attributes however are *new* and=0A=
> already complex, so we still have the option of always enclosing=0A=
> them.=0A=
=0A=
An attribute without arguments has essentially the same complexity=0A=
that a type declaration has always had. The only part that is more=0A=
complex is the optional argument list, which as stated before has=0A=
its own start/end delimiters.=0A=
=0A=
> > The RFC suggests a benefit of "Consistent colouring for being an=0A=
> > end of the attribute syntax and the keywords in between can use=0A=
> > different colors." I don't really understand this argument. How=0A=
> > would an end delimiter change the syntax highlighting provided by=0A=
> > IDEs?=0A=
> =0A=
> If you consider the three elements of an attribute declaration:=0A=
> 1. Syntax for Attributes 2. Atttribute Name 3. Arguments then if=0A=
> you color them in three different ways, then with an ending symbol=0A=
> it improves the human readability to have the end be in the same=0A=
> color [as] the beginning.=0A=
=0A=
I see what you mean now. Personally I don't think a differently=0A=
colored end bracket will be particularly helpful to readability,=0A=
though. IDEs will already highlight the argument list start/end=0A=
delimiters, and the different coloring of an attribute name from=0A=
whatever token follows it will ensure readability whether there is=0A=
an argument list or not. Ultimately perspectives on readability will=0A=
differ, though, since it's a somewhat subjective consideration.=0A=
=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=
Best regards,  =0A=
Theodore=