[VOTE] Shorter Attribute Syntax Change

Hi, One question I'd like answered is that, like me, a few people have voted NO on the question to re-vote the syntax. If that is true, shouldn't their first primary choice be implied to be <<>> instead of anything else? I see 7 votes for no, but I'm the only one that still kept the first voting choice as <<>>. On Mon, Aug 10, 2020 at 9:40 AM Rowan Tommins <rowan.collins@gmail.com> wrote:

On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins <rowan.collins@gmail.com> wrote:

For me It would indeed make a slight difference, but not wanting to speak for Theodore, I believe he did not want to add this as another option to vote upon, when I asked him. based on the argument that new also doesn't require () it makes sense to me. And for me I didn't want to add it, because then we can just go back to <<>>, which would at least be symmetrical. I.e. @@Jit() vs <<Jit>>

On Mon, 10 Aug 2020 at 15:41, Peter Bowyer <phpmailinglists@gmail.com> wrote:

Anyone? Why is the discussion fixated on [] rather than ()? Peter

On 10.08.20 17:40, Derick Rethans wrote:

For me the difference would be that with attributes, you are not opening and closing many possible statements, it can only be one (or more, with grouping) class name(s), which then can have arguments, but those are enclosed with (). In comparison, classes can have many possible definitions inside of them (class variables, methods, constants, etc.), so enclosing them clearly makes sense, as you need to know where it ends. The same goes for if, for, while, etc. So if you just have one class name as an attribute, enclosing it seems a bit overkill, as there is already a definition of a class name and how it starts and ends, which is why for me the mental parsing does not seem easier - but what is easily parseable probably depends on many factors and might be different for different people. I would have found a syntax where the delimiters are optional preferable - similar to "if", where you can leave off the {} for exactly one instruction, but you have to add them if there is more than one line of instructions. Or the group use syntax.

On Tue, Aug 11, 2020 at 3:03 PM Theodore Brown <theodorejb@outlook.com> wrote:

If typability really matters, we should've deprecated the backtick version to run things. We also seem to forget about readability. @@ makes things really hard to read for me as it draws attention, the same goes for <<and>> being written as such, with spaces it's fine. In terms of @[] typability, my IDE auto completes the ] when I type [. After that we have to type a word which will most likely require keys on the right side of the keyboard anyway. Sure, typing @@ is easier, for me this is at the cost of readability. I read code more frequently than I write it, so I think this should matter more. Please don't use @@ for annotations/attributes.

On Tue, 11 Aug 2020, Theodore Brown wrote:

They're the same on a US English/US International keyboard, both 4 presses: For @@: Shift 2 Shift 2 For @[]: Shift 2 [ ] In the case of @[], an IDE likely will automatically add the closing ]. Additionally, on a US English/US International keybaord, Shift-2 (for @) is an awkward combination to type with the pinky and middle finger of your left hand. On a UK English, it's the same amount, with the @ a little easier than on a US English one, with: left-shift @/' [ ] So if you want to add typeability to the matrix, I can do that, but @@ comes out worse. cheers, Derick

On Tue, Aug 11, 2020 at 3:03 PM Theodore Brown <theodorejb@outlook.com> wrote:

Wow, that was unexpected. By what logic? Also, how long must I wait before I can put a semicolon after the new attribute syntax? Is one whitespace enough or do I have to go to a new line? To me, suddenly disallowing semicolons at some points between statements or between a "declaration" and a statement seems to break PHP logic. Are there any precedents for this that I've missed? Best, Jakob

On Tue, Aug 11, 2020 at 11:25 AM Andreas Leathley <a.leathley@gmx.net> wrote:

The perf penalty on 7 and earlier would probably be similar to existing state of the world. Parsing a docblock is easier to fetch from the runtime (as we actually store it), but docblocks contain more than just annotations, so some plus some minus. PHP 8+ performance on theses would certainly be between though, and that's an extra carrot to push users to upgrade. If annotations can't be written until after users upgrade, then that carrot vanishes.

That's true. It'll take some care (and possible reduction in readability) to make annotations work well across verisons, but it's better to have an option than not, no? -Sara

On Tue, Aug 11, 2020 at 6:26 PM Andreas Leathley <a.leathley@gmx.net> wrote:

To clarify the forward compatibility argument: As far as I understood, it's not really about the end user, it's about the library implementing the attribute. The library providing the Route attribute can write: #[Attribute] class Route { // ... } and make the Route attribute available both for use with PHP 8 attributes and PHP 7 docblock annotations. With non-FC syntax choices this possibility does not exist, and the library will be required to provide different class hierarchies for docblock attributes and PHP 8 attributes. The ability to write #[Route] for the user of that library is an additional possibility on top of that, but one that is technically more involved. I think the primary forward compatibility value lies in the above usage. I believe this was explained in some of the earlier discussions, but I wanted to repeat it in this thread, as there seems to be some confusion on this point. Regards, Nikita

Le Thu, 13 Aug 2020 10:13:16 +0200, Michał Marcin Brzuchalski <michal.brzuchalski@gmail.com> a écrit :

I still do not understand this point on grouping, how is using a syntax like @@ or any that does not require grouping removing anything? What is the grouping feature supposed to do?

On Thu, Aug 13, 2020 at 3:13 AM Michał Marcin Brzuchalski <michal.brzuchalski@gmail.com> wrote: > Hi Theodore, > > śr., 12 sie 2020 o 18:36 Theodore Brown <theodorejb@outlook.com> napisał(a): > > On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon <pollita@php.net> wrote: > > > > > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote: > > > > > > > It has just come to my attention that this RFC was rushed to vote > > > > after less than the minimum two week period required after it was > > > > brought up on list. Furthermore, discussion was still very active at > > > > that time - I certainly didn't have a chance to respond to some of > > > > the emails before voting began. > > > > > > > > Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the > > > > vote was started this Monday at 3:41 AM, less than 12 days, 18 hours > > > > after the announcement. Per the voting rules: > > > > > > So, 30 hours short of 2 weeks. I'm going to ascribe good intentions > > > in trying to get the issue resolved in the minimal timeframe. The > > > fact active discussion was ongoing makes this a questionable choice, > > > but in my opinion, purely on a matter of time, quibbling over 30 hours > > > is splitting hairs. Maybe compromise on adding time to the vote end > > > period so that the total is greater than 4 weeks? > > > > > > > What should be done to prevent this rule from being violated? > > > > > > Vigilance. You're right to raise the concern. And let's wag a finger > > > over it at least. If others agree that it's premature, we can stop > > > the vote, but I'm not inclined to disrupt the process over such a > > > small variance. > > > > On top of violating the minimum two week discussion period, I believe > > this RFC also breaks the rule on resurrecting failed proposals. When > > I authored the Shorter Attribute Syntax RFC, I specifically did not > > include a voting option for `@:`, since this syntax was declined, > > and my understanding was that a six month waiting period is required > > before resurrecting rejected proposals. [1] > > > > But if we can vote again on `#[]` and `<<>>` after they were declined, > > why can't we also vote again for `@:`? This syntax has the advantage > > of being equally short as `@@` without any BC break. > > > > I'm really disappointed and disillusioned with how the process has > > been handled for this RFC. It seems like the rules are arbitrarily > > going out the window in order to keep voting until the desired result > > is reached. > > > > What is the point of having rules if they aren't followed or enforced? > > If anyone else is troubled by the precedent being set by this RFC, > > please vote No on the primary vote. I'm not sure what other recourse > > we have at this point. > > > > Sincerely, > > Theodore > > > > [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals > > You hint to the fact of shorter discussion period and the fact that > you haven't got time to respond to all discussions while if you take > a closer look on ML [4] that is obvious that discussion in fact began > earlier and it's 3 weeks from now and to avoid insinuation you replied > to it [5] 3 weeks ago as well. Hi Michał, The discussion thread you're referencing did not announce an RFC. Per the voting rules, a "Proposal is formally initiated by creating an RFC on PHP wiki and announcing it on the list". After that there must be a minimum two week discussion period before voting starts. The Shorter Attribute Syntax Change RFC failed to meet this requirement. > Rejected features have nothing to do with a re-vote on a syntax > change at least this is how I understand this. Besides you already > mentioned this argument on ML [1] so we can argue actually if a > re-vote on syntax change is actually resurrecting a declined > proposal since it was not a standalone proposal which got into a > declined section of RFC's index [2] and yet you did it again! So you're saying that the rule on resurrecting failed proposals only applies to primary votes, and not secondary votes? So if a secondary vote fails it's okay to vote for it again and again until the desired result it reached? This is not my understanding of the rules. > You blame others for "abusing" the RFC process while you've brought > to us an RFC with a significant ambiguity [3] which you haven't > mention and it turned out after closing a vote. Personally I think > that it was your huge failure to bring the previous @@ syntax change > RFC up to the voting without checking it's correctness. It was correct as far as we knew at the time. Anyway, this issue was fixed before the @@ syntax was merged, and I don't see its relevance to this discussion. > I'm personally also disappointed with the fact that in your RFC under > the primary vote question "Are you okay with re-voting on the > attribute syntax for PHP 8.0?" removing features like grouping > ability was hidden. I don't follow you. The grouping feature for <<>> wasn't even accepted yet when the Shorter Attribute Syntax RFC went to vote. One of the primary motivations of the Shorter Attribute Syntax RFC was to reduce verbosity and remove the need for two different syntaxes (grouped and non-grouped) for declaring attributes. It was also discussed on list how @@ is equally or more concise without grouping: https://externals.io/message/110355#110414. Finally, the Attribute Amendments RFC itself explicitly stated that the grouped attribute feature "would be superseded by any other RFC getting accepted that changes the syntax." Attribute grouping makes some sense to help reduce the verbosity of the @[], #[], and especially <<>> syntaxes, but with @@ there is no need for the extra complexity since it is equally concise without it. > Personally I think you're forcing to stop the re-vote cause of mental > connection to your previous @@ RFC and trying hard to find an argument > against the re-vote. From the results which are available so far, it > can be seen that your proposed syntax is no longer the leading one. > I understand it fully cause I'd be upset as well. If it was just a matter of my personal syntax preference I wouldn't be having this discussion. I was fine with voting on #[] originally and included it as an option in the Shorter Attribute Syntax RFC. What I have a serious problem with is breaking rules to arbitrarily vote again in the hopes that this time voters will choose #[] even though it was declined in the last vote. Moreover, the current RFC does not fairly present all the pros and cons of each syntax, and the requests of myself and others to include additional important details in the RFC about the BC breaks and other considerations have not been heeded. What is happening here is wrong, and because I want the best for PHP I have to stand up to it. Sincerely, Theodore > [1]: https://externals.io/message/111218#111254 > [2]: https://wiki.php.net/rfc#declined > [3]: https://externals.io/message/110640#110819 > [4]: https://externals.io/message/111101#111101 > [5]: https://externals.io/message/111101#111132