Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111598
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
In-Reply-To: <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
Date: Mon, 17 Aug 2020 23:56:06 +0200
Message-ID: <CAJmjfvWSiD=C8W+NLJM_391u1+-TXU1u-+KN9c1OcXob1qON0w@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: jakob@givoni.dk (Jakob Givoni)

On Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei <kontakt@beberlei.de> wro=
te:
>
> We have updated the RFC with all (hopefully) of the feedback from this
> discussion:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Most notable changes are:
> - A new section with several subsections on the benefits of a closing
> delimiter / enclosing syntax.
> - A section on grouping pro/cons
> - Inclusion of @: as per Theodores request
>
> We are looking for further feedback from the community.
>

From the updated RFC:

> There are multiple reasons why we believe the previous vote should be rev=
isited:

Ok, bring it on!

> At the point of the vote for @@, it was not clear that the syntax require=
d the namespace token RFC to be viable.
> While this is not a problem anymore, the @@ syntax might not have come ou=
t on top if this information was known beforehand.

If anything, this is an argument AGAINST this RFC. A "bad" decision
was taken. The problem with it was fixed. No need to change anything.
The argument comes across as disingenuous, I'm afraid.

Moving on...

> The #[] syntax provides the benefit of forward compatibility, but this al=
so introduces some potential problems for PHP 7 code.
> An alternative syntax @[] was suggested to eleviate these problems which =
was not previously voted on.

Ok, let's analyze the logic here as well: #[] lost the vote. #[] would
have had some problems. Are there any syntaxes we still haven't voted
on? Yes!
Come on...

And lastly...

> We argue why we should strongly favor a syntax with closing delimiter to =
keep consistency with other parts
> of the language and propose to use #[], @[], or the original << =E2=80=A6=
 >> instead.

This is the only part that contains logically valid arguments, albeit
most are subjective and speculative. Which is not to say it's not
worth voting on them.
But looking for actual facts, I only came across only this little cutie:
> For VIM users, the % operation to jump between opening and closing part o=
f declaration that would automatically work with [ and ].
I fully expect all 3 VIM users to vote in favor of this RFC ;-)

Ok, enough of my sarcasm - I only wish you'd put your strongest
arguments first and focused on quality over quantity.

- Jakob