Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111279
MIME-Version: 1.0
References: <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
 <CAEPJdu=7n_zusEAYO6wuciDkCd2npHyDyUAmuF96cxbdN5Z8Mg@mail.gmail.com>
 <CABj1Baaj9owifCCjRrMVj1CJ8EbbKi5YKzuZVpZeBCgYBKJEtA@mail.gmail.com> <DM6PR07MB6618E84A0FC2A893275ED635F9710@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB6618E84A0FC2A893275ED635F9710@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Fri, 31 Jul 2020 18:20:38 +0200
Message-ID: <CA+m0RERd5aJDY1Y_P_vLjqo1DZVBUB3Z10guH7B-oMOfPHsL=w@mail.gmail.com>
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001e56be05abbf2c82"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
From: kaznovac@gmail.com (Marko Kaznovac)

--0000000000001e56be05abbf2c82
Content-Type: text/plain; charset="UTF-8"

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 <tysonandre775@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
>
>

--0000000000001e56be05abbf2c82--