HI, [disclosure: I'm not php internals/interpreter developer; have ~10 years of using php language]
I've searched but couldn't find in this discussion: Can we keep the 'current' [doctrine/annotations or similar libraries] annotation syntax and implement parsing of metadata in PHPinterpreter? [something like having internal/native doctrine/annotations implementation that can use opcache] pros: - existing tooling will continue to work - existing code will continue to work - no need for developers to migrate their code - no need for developers to learn new syntax cons: - code comments cannot be removed from opcache :| [or can they? if metadata/annotations get parsed and attached in preload - comments can be discarded if not needed in runtime] I'm sorry if I've added some noise by missing something that's obvious; I would really appreciate it if someone from the php internal comments on this. cheers, k On Thu, Jul 30, 2020 at 7:24 PM tyson andre <tysonandre...@hotmail.com> wrote: > 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 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
