Re: [RFC] Shorter Attribute Syntax Change RFC 0.2
| From: | Michael Voříšek - ČVUT FEL | Date: | Wed, 19 Aug 2020 09:12:41 +0000 |
| Subject: | Re: [RFC] Shorter Attribute Syntax Change RFC 0.2 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-111625@lists.php.net to get a copy of this message | ||
Please add discussion about merge conflicts. Any inline grouped
attribute syntax needs a manual conflict resolution.
With ungrouped syntax, I expect recommended CS to be one attribute per
line.
If this should be the case also for grouped syntax, then it not +1
character, but +2 new lines per every annotated element.
Also, is 2/3 majority required by RFC rules satisfied by the "Are you
okay with re-voting on the attribute syntax for PHP 8.0, again?"
question?
I think we should require 2/3 votes at least on the question if we
should allow grouping or not and if accepted, use STV results on the
prefered prefix symbols/syntax.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 19 Aug 2020 10:47, Benjamin Eberlei wrote:
On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei <kontakt@beberlei.de> wrote: On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans <derick@php.net> wrote: Hi, Out of Banjamin's suggestion[1 [1]], I've updated the Shorter Attribute Syntax Change RFC to reflect that process: https://wiki.php.net/rfc/shorter_attribute_syntax_change Patches and comments welcome. FWIW, this has an excemption from the RM Sara as per [2 [2]]: * Shorter Attribute Syntax Change - Joe/Derick - Please make sure this RFC moves along and reaches conclusion by beta3, as discussed previously. Heads up: This RFC is now going to vote tomorrow:https://wiki.php.net/rfc/shorter_attribute_syntax_change I have updated the RFC one last time with as much of the feedback as possible: - a section about comparing to complexity of type definitions - removal of the machine reading section as too narrow and ultimately not that important as downstream libraries just have to deal with any of it - some more nuances in forward compatibility pro/cons section of #[] - smaller corrections and improvements. I don't think something major is missing now. One last change that I didn't see yesterday as it was on Github and not this list is the addition of another syntax proposal @{} with the same benefits as @[], a little more snowflake than compared to other languages, but without the BC Break.
Links: ------ [1] https://externals.io/message/111218#111261 [2] https://externals.io/message/111286#111286cheers, Derick [1] https://externals.io/message/111218#111261 [2] https://externals.io/message/111286#111286 -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php