Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111113
User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5
Mime-Version: 1.0
Message-ID: <25df7339-2acc-4ca3-b2b2-390d8f5ab908@www.fastmail.com>
In-Reply-To: <0E082DE8-6862-44AC-A398-D43B8806DB8D@stitcher.io>
References: 
 <alpine.DEB.2.23.453.2007221247530.7489@singlemalt.home.derickrethans.nl>
 <CADK1yXJTUwQ-5NCuPampdLqyfeHatw0=FTXZVeLt+oK67RSBNw@mail.gmail.com>
 <CAEPJdumWHMr0aVkZtKC_+HA57CcYcm90gCuhvgWeTdd8extH8A@mail.gmail.com>
 <0E082DE8-6862-44AC-A398-D43B8806DB8D@stitcher.io>
Date: Wed, 22 Jul 2020 07:58:05 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 22, 2020, at 7:49 AM, Brent Roose wrote:
> Doesn't it make the most sense to re-vote the syntax? I'd consider the 
> previous vote to be invalid given the parsing issues that weren't 
> listed in the RFC.
> 
> A re-vote seems the most fair: if the majority still prefers @@, then 
> so be it. Otherwise the syntax changes once again, before 
> feature-freeze. I suppose the RMs should have a final say in this 
> descision?
> 
> Kind regards
> Brent

One of the advantages of having conducted it as a ranked-choice-vote is that we can easily disqualify the @@ option and then recount with just the other two, counting @@ supporters' second choice.  No new vote is needed, unless we think a significant number of people would have changed their minds between << >> and #[ ] since then.  (I think that's unlikely, personally.)

IIRC, it looked like #[ ] would win that runoff but it's easy enough to recompute and be sure.

I agree this is ultimately an RM decision for how to proceed; my recommendation would be to Make A Call(tm) if the parsing issues of @@ are significant enough to disqualify it, and if so, recompute the vote as above and go with the result.

@@ may be easier to type than the others, but at the end of the day the parsing problems it introduces seem like the killer blow to me.

--Larry Garfield