Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107443
Message-ID: <82012CD7-088D-4010-922E-AD54186AE37A@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_64383DEF-6161-4C89-9A5F-064C24DB95F8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 8 Oct 2019 18:38:06 -0400
In-Reply-To: <CAJHtznwX-V8KKSyqir-BQBeaovP3+a6-EoafOFxpgGwAqth3sg@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Zeev Suraski <zeev@php.net>
References: <5d976928.1c69fb81.db3a8.78daSMTPIN_ADDED_MISSING@mx.google.com>
 <CAF+90c9uXdqJsTizLCca-AswenZDv9-6yw=ranATp3XoutHyxw@mail.gmail.com>
 <DM5PR06MB285747B847DE2D7320758C05DE9A0@DM5PR06MB2857.namprd06.prod.outlook.com>
 <e69fb3de-df5f-f77e-ad4e-61ea30185c5c@lsces.uk>
 <CAG9XoMR9DhKDwS1moH_9pjDNyZQ70ER5_stNs_GxQFucZ+ar7A@mail.gmail.com>
 <413d377a-4ce1-a521-0cb4-5bb37e84c257@gmail.com>
 <6DFA91F7-0005-453E-A314-A5DFE1A4D3D3@newclarity.net>
 <CAHN63oN3cgGaaWhYhLUVBAgRsi7d-eLODfhLGBOJetFh98zWQg@mail.gmail.com>
 <D2050867-9A1B-45D1-A51E-F7AFEE47DD69@newclarity.net>
 <CAJHtznwX-V8KKSyqir-BQBeaovP3+a6-EoafOFxpgGwAqth3sg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_64383DEF-6161-4C89-9A5F-064C24DB95F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Oct 8, 2019, at 5:34 PM, Zeev Suraski <zeev@php.net> wrote:
> So while I sympathize with the effort to find a compromise - =
encouraging more of these contentious proposals (by accommodating them =
at some level) is not the way.

Ok, but...

> The real middle ground is to go for some form of opt-in solution.  =
Whether it=E2=80=99s granular declares, strict mode, P++, editions - =
this is the only way to diffuse this contention - by rendering it =
irrelevant - precisely as it should be.  Contrary to the perception many =
here appear to be under, there=E2=80=99s no feasibility question-mark =
over any of these options - they=E2=80=99re all doable, and even easy to =
implement.  This solution would also not be some band aid until the next =
out of the blue proposal comes along - but a framework to thoroughly =
diffuse these types of contention once and for all.

...it seems you have identified at least one way to seek compromise.  =
Why not move forward with this, in general?

Said another way, why not discuss and debate BC breakage in abstract =E2=80=
=94 and any other contention topics =E2=80=94 and then establish a set =
of principles that the community can agree to use? =20

This could be done in an RFC, and much like Mission, Vision and Values =
statements that organizations use to help them decide if they should =
pursue specific opportunities, a set of principles like these could help =
the internals@ have the debates once, in abstract, and then apply those =
principles to evaluate future RFCs?  If course really cut down on =
ongoing contentious debate.

I would create an RFC like that but AFAIK I have not developed enough =
clout here thus far so it would have to be from someone already well =
respected.

-Mike

P.S. You argument against compromises ironically  soundsvery similar to =
the argument that leaving certain syntax in PHP encourages people to use =
it, and thus write "bad" code.  Do you not see the similarities?=

--Apple-Mail=_64383DEF-6161-4C89-9A5F-064C24DB95F8--