Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111269
MIME-Version: 1.0
References: <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
 <CAEPJdu=7n_zusEAYO6wuciDkCd2npHyDyUAmuF96cxbdN5Z8Mg@mail.gmail.com>
 <CABj1Baaj9owifCCjRrMVj1CJ8EbbKi5YKzuZVpZeBCgYBKJEtA@mail.gmail.com> <CALKiJKp_yYP2wyvUitn1fXofywu524O9a6-zYAYXb_8GweAQAg@mail.gmail.com>
In-Reply-To: <CALKiJKp_yYP2wyvUitn1fXofywu524O9a6-zYAYXb_8GweAQAg@mail.gmail.com>
Date: Thu, 30 Jul 2020 12:18:20 -0400
Message-ID: <CAFp73XuJCZ3pHLxG91xW9RFQig=7EctyuOcZOoQ+wj-r25qHDQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

Question: The key factor of not using @ is due to conflict of
suppression symbol.
While we are in a major (where BC breaks are not encourage, but
tolerable), have we considered the possibility of BC breaking
suppression symbol (@ would become @@) and using @ for Attributes?

I bet a search/replace wouldn't be that hard to be achieved, and it
would function even today (as @@ is acceptable). Basically, it's a BC
break where code needs to be changed, but backwards compatible as new
suppressor symbol is backwards compatible with previous versions of
PHP.

Just some food for thought....

On Thu, Jul 30, 2020 at 11:57 AM Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> 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]



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599