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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
