Re: [RFC] [Discussion] Shorter Attribute Syntax Change
| From: | tyson andre | Date: | Thu, 30 Jul 2020 17:24:07 +0000 |
| Subject: | Re: [RFC] [Discussion] Shorter Attribute Syntax Change | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-111273@lists.php.net to get a copy of this message | ||
Hi Joe Ferguson,
> Now that it seems the technical concerns around @@ have been resolved by
> another pending, passing, RFC, I'm still here wanting us to talk about the
> impact of @@ on static analysis tools. Apparently, internals doesn't care
> about these projects. I care and I'm trying to help. I'm not trying to
> revote until I get the vote I want. I'm just a dude that had some free time
> while on vacation when he saw a chance to contribute.
3 commonly used static analyzers (for type inference) are
- PHPStan and Psalm, both of which use nikic/php-parser. As Nikita Popov (the maintainer of
php-parser) wrote,
> Emulating #[] lexing on older versions will
> definitely be a challenge for PHP-Parser. I don't think we should make
> concerns of external tooling hold us back too much, but the phpcs argument
> really doesn't hold water.
Comparatively, it would be easy to join two adjacent
@ tokens to a single
@@ token in a single pass over token_get_all.
Parsers would likely already do that or benefit from doing that for tokens such as the
match token (T_MATCH) in php 8.0.
Another commonly used static analyzer is Phan (https://github.com/phan/phan/) , which I am a
maintainer of.
My reasons for preferring <<>> or @@ over #[ were mentioned in
https://externals.io/message/111218#111239
.
For phpcs and other linters, my belief is that this might be easier for simple use cases in the
short term,
but edge cases or ambiguities like multi-line attributes or refactorings that were safe in php 7
(such as moving #[] behind other tokens to another line)
may cause issues for users of those tools (until those tools drop support for php 7.x and older).
This is why I'd advocate for a distinct token that doesn't overlap with line comments
Cheers,
- Tyson