Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111268
MIME-Version: 1.0
References: <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
 <CAEPJdu=7n_zusEAYO6wuciDkCd2npHyDyUAmuF96cxbdN5Z8Mg@mail.gmail.com> <CABj1Baaj9owifCCjRrMVj1CJ8EbbKi5YKzuZVpZeBCgYBKJEtA@mail.gmail.com>
In-Reply-To: <CABj1Baaj9owifCCjRrMVj1CJ8EbbKi5YKzuZVpZeBCgYBKJEtA@mail.gmail.com>
Date: Thu, 30 Jul 2020 16:57:06 +0100
Message-ID: <CALKiJKp_yYP2wyvUitn1fXofywu524O9a6-zYAYXb_8GweAQAg@mail.gmail.com>
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000011811005abaaba87"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000011811005abaaba87
Content-Type: text/plain; charset="UTF-8"

On Thu, 30 Jul 2020 at 14:28, Joe Ferguson <joe@joeferguson.me> wrote:

> ... 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 don't think that's a reasonable summary of this thread at all. I've seen
three main types of response:

1) "I haven't followed the discussion about PHPCS, please could you
summarise the problem."
2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x
syntax."
3) "I think #[] will cause as many problems for such tools as @@, just in
different places."

Maybe they weren't always as polite or succinct as that, but not agreeing
with you is not the same as not caring.


As far as I can make out, attributes that appear entirely on a single line
with no other text are trivial to ignore in any parser whatever the syntax.
That trivial case is slightly more trivial with #[] because a PHP 7 parser
will treat it as a line comment; but add a rule to your parser to also
treat "@@" as a line comment, and you're done.

The problems come when you have a) an attribute definition spanning
multiple lines, and/or b) an attribute definition inline with other code.
As soon as you have that, you have no choice but to parse the code entirely
according to the grammar of PHP 8, not as "PHP 7 with some warts".

If detecting the end of annotation tokens is really that difficult, would
it suffice to make the () mandatory (i.e. @@Deprecated() rather than
@@Deprecated)? The rules for what could appear between @@ and ( are pretty
simple, and finding the correct ending ) should be pretty much the same
effort as finding the correct ending ], since both can occur in matching
pairs inside the argument list.

Regards,
-- 
Rowan Tommins
[IMSoP]

--00000000000011811005abaaba87--