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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to