Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111625
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_1ff25196bacef1320b41f0a2b6b7f869"
Date: Wed, 19 Aug 2020 11:12:41 +0200
To: internals@lists.php.net
In-Reply-To: <CAEPJdumb5KmS04-qnGLfHf4mdbSbXcBf_1+67JvWcyyuJDtHZg@mail.gmail.com>
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl> <CAEPJduk12mo-eizR=K7G9TdaMdk7=C5iq88QWwQ6B_tk02r=2w@mail.gmail.com>
 <CAEPJdumb5KmS04-qnGLfHf4mdbSbXcBf_1+67JvWcyyuJDtHZg@mail.gmail.com>
Message-ID: <7175bd91edc27cd1ba768d574ccfbc4a3400d10a0eb506d2a359e1b3fda8dd27@mahalux.com>
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: vorismi3@fel.cvut.cz (=?UTF-8?Q?Michael_Vo=C5=99=C3=AD=C5=A1ek_-_=C4=8CVUT_FEL?=)

--=_1ff25196bacef1320b41f0a2b6b7f869
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8; format=flowed

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
--=_1ff25196bacef1320b41f0a2b6b7f869--