Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111599
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com> <CAJmjfvWSiD=C8W+NLJM_391u1+-TXU1u-+KN9c1OcXob1qON0w@mail.gmail.com>
In-Reply-To: <CAJmjfvWSiD=C8W+NLJM_391u1+-TXU1u-+KN9c1OcXob1qON0w@mail.gmail.com>
Date: Tue, 18 Aug 2020 01:03:52 +0300
Message-ID: <CANeKSiTB7E0FCCeWKkYoUbeG0pgcf0fzn0czpOs5s9qCG7exCw@mail.gmail.com>
To: Jakob Givoni <jakob@givoni.dk>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, Derick Rethans <derick@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f1d4d105ad19f286"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000f1d4d105ad19f286
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 18, 2020, 12:56 AM Jakob Givoni <jakob@givoni.dk> wrote:

> On Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei <kontakt@beberlei.de>
> wrote:
> >
> > 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
> revisited:
>
> Ok, bring it on!
>
> > At the point of the vote for @@, it was not clear that the syntax
> required the namespace token RFC to be viable.
> > While this is not a problem anymore, the @@ syntax might not have come
> out 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.
>


And then boo-yah, 6 months later we want to implement a cool new feature to
attributes (a lot of examples were said before, ain't repeating myself) but
we can't :(( because there is no ending delimiter and thus, we will run
into parsing issues.


> Moving on...
>
> > The #[] syntax provides the benefit of forward compatibility, but this
> also introduces some potential problems for PHP 7 code.
> > An alternative syntax @[] was suggested to eleviate these problems whic=
h
> 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


What problems? Besides the BC breaks that all of the syntaxes (except
`<<...>>`) have, there are no problems.

syntaxes we still haven't voted
> on? Yes!
> Come on...
>
> And lastly...
>
> > We argue why we should strongly favor a syntax with closing delimiter t=
o
> 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
> of 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.
>

I wish someone actually gave reasonable arguments as to why `@@` is better.
Because a) no one cares if we have to type 2 or 3 characters b) `@@` does
not ensure 100% safe future c) it does not decrease complexity in any way.


> - Jakob
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000f1d4d105ad19f286--