Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111240
MIME-Version: 1.0
References: <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
In-Reply-To: <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
Date: Wed, 29 Jul 2020 03:11:58 +0200
Message-ID: <CAEPJduk=5_BCL+OVix1K86JEm3QTtyzVv=h+35uu7mr3mGX9Ew@mail.gmail.com>
To: Joe Ferguson <joe@joeferguson.me>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bb778b05ab8a3ea2"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000bb778b05ab8a3ea2
Content-Type: text/plain; charset="UTF-8"

Hi Joe,

Personally I favor #[] myself, but there has been a vote with a substantial
participation choosing @@. Overturning this democratic outcome should
require **significant** technical arguments, otherwise this RFC would
provide problematic precedent for any RFC to be overturned by arbitrary
revoting.

The arguments the RFC brings forward don't convince me that we should pick
#[] over @@.

1. The parser conflict was my major reason why @@ should not have been
picked from a technical POV. But this issue has been fixed by an
independent improvement since then. These kinds of small problems are found
regularly after RFCs are accepted and are subsequently fixed. The RFC is
formulated as the problem still exists, but it does not. Yes, the namespace
token RFC vote has not yet finished, but there is no chance it will be
rejected at this point.

Since the namespace token RFC is passing, and I have seen the simplicity of
the new parser rules, my opinion has changed to keep pushing for #[] and I
accept the @@ outcome.

2. The phpcs argument also does not convince me.

Summed up it is essentially that a current version of phpcs does not
support parsing @@ or <<>> yet and incorrectly changes code using them,
however for #[] it does nothing because it parses it as a comment. To me
this sounds like a bug in PHPCS. This argument also breaks down completely
on multi line attributes.

Why should we even expect PHPCS to support an unreleased version? If
someone uses PHP 8 code, why do we assume they keep using an old version of
phpcs that does not support PHP 8 yet?

3. We already established that the syntax question is extremely
contentious, and I was getting tons of messages on it on Twitter, Reddit,
Email et al during the initial Attributes RFC. So of course people would be
against @@ (as I am myself), however it had a majority in votes.

For me putting these subjective opinions into the RFC makes the case for
overturning less convincing, because it makes the argument that overturning
a valid democratic vote is somehow OK if you are loud.

The only reason why we change this outcome must be purely technical imho.

4. You cannot write a regex to detect the end symbols for both #[] or <<>>,
because both end symbols are allowed *inside* the attribute syntax already,
so it's not easier to find occurrences with regexes with the other syntaxes:

#[Foo([1 => 2])]
<<Foo(1 >> 4)>>

Simple detection of attributes will always need to grep only for the start
token, and both @@ and #[ are equally unique to find here.

5. For readability an end token would be nicer (which is why i prefer #[]).
But this information was already known during the first vote on the syntax
and rejected by majority.

6. An end token might indeed allow extending attributes with new stuff, but
nobody has brought up this use-case before. No other language has
additional attribute keywords, why is this brought as a positive argument,
when the choice of syntax no other language uses is brought up as a
negative point later?

7. Future potential parsing problems are brought forward for @@, but #
being a comment token makes it likely that #[] will also cause problems.
Tyson has a few examples in his email to this thread.

Other confusing things you can do with #[] for example:

#[Foo( 1 # 1 ] bar
)]
function foo () { }

Which is #[Foo(1)] without comments and line breaks.

--000000000000bb778b05ab8a3ea2--