Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111514
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008100935570.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB65355FFBB6717491995EEBF4DE420@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CAESVnVqraG9V4VMrxrv5AOFX5Jt7Cx0-uo5L0doQEWcUVOdHkg@mail.gmail.com>
 <BYAPR05MB65356FCC029CD06F49F528A0DE420@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CABdc3WobP1HSRwcujd4=o4wv3QUp7gDT12KmMRQU1_wLj4YLuQ@mail.gmail.com>
 <BYAPR05MB65351C807797676BB08D8BDCDE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <5cc837df-ab47-628a-d29b-46d7933be973@gmx.net> <BYAPR05MB653522F9123B59F7E066BDB8DE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <3A7CECC3-CDEE-4852-BF4B-4EC7CA1BD538@pmjones.io> <CAAKU0u=VYh7D+XJ93dDdAxdJ8nEU8iPfeN0f=Xv9Qm=cCQKX6w@mail.gmail.com>
 <BN8PR05MB6532D19BEA11F44BAAD3FDD3DE400@BN8PR05MB6532.namprd05.prod.outlook.com>
In-Reply-To: <BN8PR05MB6532D19BEA11F44BAAD3FDD3DE400@BN8PR05MB6532.namprd05.prod.outlook.com>
Date: Fri, 14 Aug 2020 16:16:25 +0200
Message-ID: <CAEPJdukoJR_dmYehaiWO_7XTCOnOvuDYtKpPWQSV+V+yhNGfhA@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, Derick Rethans <derick@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>, Sara Golemon <pollita@php.net>
Content-Type: multipart/alternative; boundary="000000000000a14fea05acd711c7"
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000a14fea05acd711c7
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown <theodorejb@outlook.com>
wrote:

> On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison <levi.morrison@datadoghq.com>
> wrote:
>
> > > So, a week+ early, then? Surely that means the current vote null
> > > and void, to be reset entirely following a proper discussion period
> > > -- one without concurrent voting.
> >
> > I just want to make sure I understand: there are people who think we
> > haven't discussed the syntax for attributes yet?
> >
> > I assume this is a serious email, but I can't fathom why anyone cares.
> > We've discussed this subject soo much...
>
> Hi Levi and internals,
>
> There's certainly been a lot of discussion in general about
> attributes. However, there was not a reasonable opportunity to either
> discuss the specific arguments made in this RFC (e.g. the lack of a
> closing symbol being inconsistent), or submit patches for alternative
> syntaxes as Derick requested when he put up the RFC for discussion.
>
> I was very surprised that it went to vote less than six days after
> the discussion period started, right after the weekend no less,
> before I had a chance to submit my patch to include the @: syntax.
>
> I'm as weary of the discussion as anyone, and would like to see
> closure on this topic sooner rather than later. But if the voting
> rules aren't followed, how can the vote result be considered
> legitimate or binding?
>
> If the authors sincerely want the best outcome for the language (and
> I assume they do), what harm is there in deferring the vote until the
> discussion period has completed, and ensuring that the RFC addresses
> the arguments on both sides and contains all the relevant information
> for making a decision? Otherwise many contributors (myself included)
> just end up feeling unheard, unhappy, and unconfident that the right
> choice is being made.
>
> With this in mind, I'd like to respectfully make the following
> requests:
>
> 1. Defer voting until the two week discussion period is complete
> (Tuesday, August 18).
>

What do you mean by defer exactly? Stop voting or reset the vote? We were
thinking of extending the vote until September 1st.

>
> 2. Include a ranked voting option for @: and mention its pros and
> cons (it is equally concise as @@ with no BC break, but is somewhat
> harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1
>

I am wondering where @: is suddenly coming from? It wasn't discussed in
both shorter attributes RFC and the discussion leading to this RFC.

There were a few other suggestions like $() or "using attribute", but none
of them was followed up upon. Nobody replied to my or Dericks message with
a specific interest in actually contributing another patch, including @:

>
> 3. Add a Backward Incompatible Changes section with examples of the
> code that the different syntax options would break.
>

Derick and I are working on this section to update the RFC later today. We
didn't consider this relevant, because the mitigation steps for all of them
is the same: a project wide search and replace to insert a space

Code search across open-source showed that the number of occurrences vary,
but are all extremely low.

In addition all BC breaks are clean cut and lead to a fatal error that is
unlikely to go undetected when upgrading to PHP 8 (specifically in contrast
to the number conversion RFCs BC breaks).


> 4. Add a Discussion section briefly summarizing the arguments that
> have come up on list. In particular this should include:
>     a) Tyson's examples of #[] changing the meaning of code in
>        unexpected ways between PHP 7 and 8 (e.g. a parameter
>        attribute would remove the parameter when run on PHP 7).
>

This is also included in the update, but ultimately is covered by the
explanation for "Forward Compatibility" already mentioning that it does
only work with a subset (and hence does not work for some other subset).

    b) An example of the downside of grouping, where it causes
>        unnecessary diff noise when adding or removing a second
>        attribute on its own line.
>

This is a problem for coding styles to solve and is nothing the RFC should
be concerned with. Grouped syntax specifically includes support trailing
commas. Diff noise is something all declarations
with optional elements can cause, even use of @@ in one line can be
"forced" from single to multi lines creating diff noise under reasonable
Coding Standard assumptions.
As such I don't want to add coding style considerations at all, because
everyone is free to make them on their own anyways.

I'd be willing to help draft this section if the RFC authors so desire.
>
> Derick and Benjamin (and Sara), are these requests reasonable? If the
> RFC follows the discussion period rule and contains all the relevant
> information, I will be much more confident that it is resulting in
> the best long term outcome (and I think this would speak for many
> others on list as well).
>
> Sincerely,
> Theodore

--000000000000a14fea05acd711c7--