Re: [RFC] Shorter Attribute Syntax Change RFC 0.2

From: 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.
cheers, 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
Links: ------ [1] https://externals.io/message/111218#111261 [2] https://externals.io/message/111286#111286

« previous php.internals (#111625) next »