Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111606
To: internals@lists.php.net
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>
Message-ID: <3420326b-9853-2d65-3ba5-dcecec785dec@seld.be>
Date: Tue, 18 Aug 2020 09:28:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CAEPJdunPh1JudU6-_+v=4a9jpha289GWqcOdbvDtHySJJsnYhg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: j.boggiano@seld.be (Jordi Boggiano)

Hi Benjamin,

>> ## Easier machine parsing?
>>
>> The RFC shows a list of different ways that attributes with the `@@`
>> syntax can end, and claims "This makes programmatic token based
>> scanning for attribute syntax without a closing delimiter such as `@@`
>> unnecessarily complicated."
>>
>> But I've worked with userland token stream scanners myself, and it's
>> not difficult to skip `T_WHITESPACE` and `T_COMMENT` tokens. Once you do
>> that, parsing an attribute is as simple as finding any `T_ATTRIBUTE`
>> token followed by the name token, then checking for an optional
>> argument list. If there's not an argument list, that's then end of
>> the attribute, otherwise the end is the end of the argument list.
>>
>> With the `@[]` and `#[]` syntaxes, a userland token parser is actually
>> *more* complex due to grouping. It not only has to do the same things
>> listed above, but it also has to check whether there are multiple
>> comma-separated attributes between the start/end delimiters (making
>> sure not to confuse a comma-separated attribute with a comma-separated
>> argument, or the end of an array argument with the attribute end
>> delimiter).
>>
>> So I don't understand how the RFC can claim that attributes without
>> an end symbol "introduce additional complexity" for machines, when if
>> anything the opposite is true.
>>
>> (And don't get me started about the extra difficulty for token stream
>> scanners with the `<<>>` syntax which has no `T_ATTRIBUTE` token).

I noticed you did not answer this point at all, I know there are lots of 
emails to reply to but IMO this is quite an important dismissal of one 
of the few technical arguments made for grouping, and also something I 
tried to hint at on Twitter back on Sunday..

Reading the RFC again now, IMO the whole "Machine Scanning for End of 
Attribute Declaration" section should be removed.

 From the points left, only "Potential Future Benefits of Enclosed 
Delimiter Syntax" is technically valid but really dependent on what we 
see as interesting future use cases. The rest is rather subjective and 
thus not really worth discussing, it'll be up to everyone's preference.

Best,
Jordi

--
Jordi Boggiano
@seldaek - https://seld.be