Re: [RFC] Shorter Attribute Syntax Change RFC 0.2

On Tue, Aug 18, 2020 at 12:04 AM Benas IML <benas.molis.iml@gmail.com> wrote: > >> >> 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. > 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 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 > > > 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 << … >> >> > 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.. > @@ 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