Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111567
To: Benjamin Eberlei <kontakt@beberlei.de>, Derick Rethans <derick@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Thread-Index: AQHWamWKUBRwNDrYsUOzfoBQKi8o6Kk6jJOAgAEDLLY=
Date: Mon, 17 Aug 2020 01:06:37 +0000
Message-ID:
 <BYAPR05MB65352E2180151559DDFA1E91DE5F0@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>,<CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
In-Reply-To:
 <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [hu9HFWdn7mWEAQpMn2eVTtQrnVZfayVF]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: d015341a-08f3-454e-ddad-08d84249caae
x-ms-traffictypediagnostic: DM6NAM11HT187:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 pb8w2NxzdqrG4kNhCHrzqTVrZ6b5U6jINo5La5c6IOpC65zGKTcfhQsiD3x3I9PiaHKxCtpgjO7sCGOAEiAOzju/YoRLY8SMinHH6KjmzP2VptoxCUC2NyvxJA8sa8+APHRjqx2IlyBOS5I+fnCIxuAVOkOuyC6jGiRD0lz53DogfZ0ylCC7CkRoPWSccEii3vRd+jpz6OHWe6GKqwhqO2HyPCehgj4mHJdbDlK4WBA9Z0MxMdbKAMdOphTJFOqh
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:
 oq+/MgZohWEYthJz1R5SiKWItXMnobFtDQXd+aTvHKqS+LW4VXpyP5ONLYvV9uufe+Gw4gAFNC7qbczG8xOkDdNf2LPDPUUlMlQRkw9KrnSifclq1QdPYTQ61S1OcEmCfCDIpLHv5IO7NVYbV8wG0w==
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: DM6NAM11FT034.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d015341a-08f3-454e-ddad-08d84249caae
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 01:06:37.2369
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT187
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: theodorejb@outlook.com (Theodore Brown)

On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei <kontakt@beberlei.de> wrot=
e:=0A=
=0A=
> We have updated the RFC with all (hopefully) of the feedback from=0A=
> this discussion:=0A=
>=0A=
> https://wiki.php.net/rfc/shorter_attribute_syntax_change=0A=
> =0A=
> Most notable changes are:=0A=
> - A new section with several subsections on the benefits of a closing=0A=
> delimiter / enclosing syntax.=0A=
> - A section on grouping pro/cons=0A=
> - Inclusion of @: as per Theodores request=0A=
> =0A=
> We are looking for further feedback from the community.=0A=
=0A=
Hi Benjamin and Derick,=0A=
=0A=
Thank you for taking the time to further flesh out the RFC and=0A=
include the `@:` syntax option. Overall it is a lot better now.=0A=
However, I still have some concerns with several claims in the RFC=0A=
that are inaccurate or incomplete, particularly in the "Discussion=0A=
on Ending Delimiter / Enclosing Delimiters" section. [1]=0A=
=0A=
The RFC intro says "we should strongly favor a syntax with closing=0A=
delimiter to keep consistency with other parts of the language". It=0A=
is then argued that "Many complex syntax constructs in PHP have an=0A=
ending delimiter", and therefore attributes should have one as well.=0A=
=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=
The RFC responds to this counterargument with a series of four=0A=
claims, none of which is fully accurate in describing declaration=0A=
modifiers:=0A=
=0A=
1. Even if we only consider keyword declaration modifiers, the claim=0A=
that "these modifier keywords all have only exactly one token that=0A=
can immediately follow them, T_WHITESPACE" is not correct. Just as=0A=
with attributes, modifier keywords can also be followed by a comment=0A=
token (#, //, or /**/):=0A=
=0A=
        @@Attribute// some comment=0A=
        final// some comment=0A=
        class Foo {...}=0A=
=0A=
Strangely, the RFC only lists keywords like public and final as=0A=
declaration modifiers, and neglects to mention that type declarations=0A=
are also in this category (which I have pointed out in all my=0A=
previous responses to this argument).=0A=
=0A=
Type declarations can be not only followed by whitespace and comment=0A=
tokens, but also a `T_VARIABLE` token:=0A=
=0A=
    function foo(Type$bar) {}=0A=
=0A=
2. The RFC goes on to claim that "[declaration modifiers] are all=0A=
non-complex and are only made up of a handful ascii letters". Again,=0A=
this fails to consider type declarations, which can contain the same=0A=
non-ascii characters that attribute names can.=0A=
=0A=
3. Next, the RFC says "these keywords are always on a single line".=0A=
But union type declarations can be spread across multiple lines,=0A=
and still don't have an end delimiter:=0A=
=0A=
        function foo(=0A=
            \My\FullyQualified\ClassName=0A=
            |string $param=0A=
        ) {...}=0A=
=0A=
4. Finally, the RFC says that "visibility keywords are only boolean=0A=
or bitflags in Reflection, but Attributes are a full fledged=0A=
`ReflectionAttribute` representing their own distinct language concept."=0A=
You can probably guess where I'm going with this... Type declarations=0A=
are likewise a fully fledged `ReflectionType` representing their own=0A=
distinct language concept.=0A=
=0A=
So the RFC's argument that attributes need to have a distinct ending=0A=
symbol for consistency is not convincing. The lack of an ending=0A=
delimiter is fully consistent with other declaration modifiers,=0A=
whether simple or complex.=0A=
=0A=
## Benefits for IDEs and editors?=0A=
=0A=
The RFC suggests a benefit of "Consistent colouring for being an end=0A=
of the attribute syntax and the keywords in between can use different=0A=
colors." I don't really understand this argument. How would an end=0A=
delimiter change the syntax highlighting provided by IDEs?=0A=
=0A=
Another suggested benefit is that IDEs can "Implement regions to=0A=
open/close the grouped declaration of one or multiple attributes."=0A=
But IDEs can still do this without an end delimiter, and groups of=0A=
attributes could even be opened/closed independently by separating=0A=
them with an empty line (which should improve readability for humans=0A=
as well).=0A=
=0A=
## Easier machine parsing?=0A=
=0A=
The RFC shows a list of different ways that attributes with the `@@`=0A=
syntax can end, and claims "This makes programmatic token based=0A=
scanning for attribute syntax without a closing delimiter such as `@@`=0A=
unnecessarily complicated."=0A=
=0A=
But I've worked with userland token stream scanners myself, and it's=0A=
not difficult to skip `T_WHITESPACE` and `T_COMMENT` tokens. Once you do=0A=
that, parsing an attribute is as simple as finding any `T_ATTRIBUTE`=0A=
token followed by the name token, then checking for an optional=0A=
argument list. If there's not an argument list, that's then end of=0A=
the attribute, otherwise the end is the end of the argument list.=0A=
=0A=
With the `@[]` and `#[]` syntaxes, a userland token parser is actually=0A=
*more* complex due to grouping. It not only has to do the same things=0A=
listed above, but it also has to check whether there are multiple=0A=
comma-separated attributes between the start/end delimiters (making =0A=
sure not to confuse a comma-separated attribute with a comma-separated=0A=
argument, or the end of an array argument with the attribute end=0A=
delimiter).=0A=
=0A=
So I don't understand how the RFC can claim that attributes without=0A=
an end symbol "introduce additional complexity" for machines, when if=0A=
anything the opposite is true.=0A=
=0A=
(And don't get me started about the extra difficulty for token stream=0A=
scanners with the `<<>>` syntax which has no `T_ATTRIBUTE` token).=0A=
=0A=
## Forcing @@ attributes to end with parenthesis?=0A=
=0A=
I don't really see the point of this section in the RFC. What issue=0A=
would forcing an end parenthesis solve? And what does whitespace=0A=
between the attribute name and argument list have to do with anything?=0A=
Such whitespace is allowed with *all* of the proposed syntaxes.=0A=
=0A=
I do agree, though, that requiring an end parenthesis for `@@` would=0A=
be inconsistent with object instantiation - that's one of the main=0A=
reasons I didn't require it in the Shorter Attribute Syntax RFC.=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=
## Attribute nesting=0A=
=0A=
The RFC points out that all the syntaxes can allow attribute nesting,=0A=
which is true. However, it would be nice to include an example of=0A=
potential future nesting for each syntax, as was included in the=0A=
original Shorter Attribute Syntax RFC. The reason is that some of the=0A=
syntaxes are less readable than others when nested (particularly `<<>>`,=0A=
though arguably `#[]` and `@[]` as well since the attribute end =0A=
delimiter can be confused with the end bracket of an array argument.=0A=
=0A=
    @@JoinTable(=0A=
        "User_Group",=0A=
        @@JoinColumn("User_id", "id"),=0A=
        @@JoinColumn("Group_id", "id"),=0A=
    )=0A=
    private $groups;=0A=
    =0A=
    #[JoinTable(=0A=
        "User_Group",=0A=
        #[JoinColumn("User_id", "id")],=0A=
        #[JoinColumn("Group_id", "id")],=0A=
    )]=0A=
    private $groups;=0A=
    =0A=
    @[JoinTable(=0A=
        "User_Group",=0A=
        @[JoinColumn("User_id", "id")],=0A=
        @[JoinColumn("Group_id", "id")],=0A=
    )]=0A=
    private $groups;=0A=
    =0A=
    <<JoinTable(=0A=
        "User_Group",=0A=
        <<JoinColumn("User_id", "id")>>,=0A=
        <<JoinColumn("Group_id", "id")>>,=0A=
    )>>=0A=
    private $groups;=0A=
    =0A=
    @:JoinTable(=0A=
        "User_Group",=0A=
        @:JoinColumn("User_id", "id"),=0A=
        @:JoinColumn("Group_id", "id"),=0A=
    )=0A=
    private $groups;=0A=
=0A=
=0A=
With appreciation,  =0A=
Theodore=0A=
=0A=
[1]: https://wiki.php.net/rfc/shorter_attribute_syntax_change#discussion_on=
_ending_delimiterenclosing_delimiters=