Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111618
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> <CANeKSiTB7E0FCCeWKkYoUbeG0pgcf0fzn0czpOs5s9qCG7exCw@mail.gmail.com>
In-Reply-To: <CANeKSiTB7E0FCCeWKkYoUbeG0pgcf0fzn0czpOs5s9qCG7exCw@mail.gmail.com>
Date: Tue, 18 Aug 2020 23:19:22 +0200
Message-ID: <CAJmjfvUJdV-z9JwXt5vbtz+tP7zzwPc+cbqR6Ojs+cSAw84oYg@mail.gmail.com>
To: Benas IML <benas.molis.iml@gmail.com>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, 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 Tue, Aug 18, 2020 at 12:04 AM Benas IML <benas.molis.iml@gmail.com> wrot=
e:
>
>>
>> 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 requ=
ired 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 parsin=
g issues.
>

Don't really understand how that is a response to my argument.
However, I understand your opinion, I just find it hard to find
convincing evidence in support of it in this RFC.

>>
>> 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 whi=
ch 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.
>

I'm just quoting the RFC here, then paraphrasing. If you want to know
what "potential problems" #[] introduces for PHP7 code, you'll have to
ask the authors of the RFC.

>> 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 par=
t 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 bette=
r. Because a) no one cares if we have to type 2 or 3 characters b) `@@` doe=
s not ensure 100% safe future c) it does not decrease complexity in any way=
.
>

@@ already won the vote. The burden of proof for superseding the
popular vote should be on the RFC authors. But for the record, I
visually and mentally like all the examples with @@ more than their
block-syntax counterparts. As I said previously; without hard facts,
it's just a subjective matter. If I'm a weirdo for actually liking @@
I'm not sorry :-D

Best,
Jakob