Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111232
Message-ID: <DEA9035F-AA0C-4E7E-A8D0-C644968F9D00@pmjones.io>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0D5AF2D3-1100-4485-90F4-6A0960A0512A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 28 Jul 2020 14:39:25 -0500
In-Reply-To: <0BAF2BAE-3C51-40BF-95F5-7CFC4531FBE0@benramsey.com>
Cc: Theodore Brown <theodorejb@outlook.com>,
 Joe Ferguson <joe@joeferguson.me>,
 PHP Developers Mailing List <internals@lists.php.net>
To: Ben Ramsey <ben@benramsey.com>
References: <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
 <BYAPR05MB6535E638D874FB9D6653411CDE730@BYAPR05MB6535.namprd05.prod.outlook.com>
 <79DC1760-6BBC-45E2-A5CC-0E0C076204B7@pmjones.io>
 <F4892712-BACE-4A0A-BA45-3F251108AA1C@benramsey.com>
 <E8F090F9-5B1D-445F-99F1-CD6795B675E1@pmjones.io>
 <0BAF2BAE-3C51-40BF-95F5-7CFC4531FBE0@benramsey.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
From: pmjones@pmjones.io ("Paul M. Jones")

--Apple-Mail=_0D5AF2D3-1100-4485-90F4-6A0960A0512A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Jul 28, 2020, at 14:15, Ben Ramsey <ben@benramsey.com> wrote:
>=20
>> On Jul 28, 2020, at 14:10, Paul M. Jones <pmjones@pmjones.io> wrote:
>>=20
>>> On Jul 28, 2020, at 14:07, Ben Ramsey <ben@benramsey.com> wrote:
>>>=20
>>>> On Jul 28, 2020, at 13:55, Paul M. Jones <pmjones@pmjones.io> =
wrote:
>>>>=20
>>>> Now, it may be that #[] or <<>> or something else actually is =
"better" in some sense that cannot be articulated. But if there are no =
existing technical hurdles to be overcome with the =
already-voted-on-and-accepted solution of @@, what technically =
compelling reason can there be to revote?
>>>=20
>>>=20
>>> IMO, there is no compelling reason to revote other than the fact =
that we have no process for what to do in this situation.
>>=20
>> What "situation" is this, exactly? AFICT we have a working =
implementation using @@, with no technical hurdles to surmount. Or have =
I missed something that now prevents @@ from working per its RFC?
>=20
>=20
> The new RFC outlines reasons why `@@` is a sub-optimal choice.

And yet it was the one chosen by the voting process. (Silly voters, =
making sub-optimal choices!)

The rest of your message reveals what I thought was true: i.e., there =
are no currently-verified technical barriers to @@. To wit:


> * current parser conflict (which can be worked around)

AFAICT that pre-existing problem has been fixed, so this is a non-issue.


> * possibility for further (as of yet unknown) parsing issues

IOW, imaginary issues, aka FUD.


> * a closing ] makes it easier to extend Attributes with more syntax,  =
and at the same time not be at the risk of running into parser conflicts

Maybe, maybe not. This has the strongest possibility of becoming a =
technical argument, but no competing implementation (with a comparative =
implementation using @@)  has been presented as an example. So as it =
stands now, this also is imaginary.


> * userland analysis tools have difficulties parsing `@@`

Though it does not seem insurmountable for those userland authors. Also, =
this is an interesting take: does Internals now defer to userland? If =
so, maybe it's time to open up voting more widely, so that the whole of =
userland can be represented more effectively here.

Again, I don't especially care if @@, <<>>, or #[], or something else =
makes it through. Annotations of some sort seem like a nice idea, and I =
think they'd be of benefit.

But if we are to make decisions by what is ostensibly a democratic =
process, we should stick to the voted decisions, instead of re-voting =
issues until the voters "get it right" according to some implicit and =
unstated criteria.  (If re-voting over and over is the plan, I've got =
some RFCs I might like to revisit as well.)


--=20
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--Apple-Mail=_0D5AF2D3-1100-4485-90F4-6A0960A0512A--