Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107471
MIME-Version: 1.0
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>
 <82012CD7-088D-4010-922E-AD54186AE37A@newclarity.net> <CAJHtznweQuiXZff=O=d1=JNZCLU-+dJ=eZ49Ev0bc9zp1aC1Ag@mail.gmail.com>
 <ed3411a8-2be7-4555-be8e-adb45462d992@www.fastmail.com> <67A49D41-A65F-4C07-82B2-1C19F17B2200@newclarity.net>
 <826c5050-6f7b-33c8-d856-60996b6210f3@gmail.com> <CC00FB75-E929-4AE6-9E95-A38FA53DA6BB@newclarity.net>
In-Reply-To: <CC00FB75-E929-4AE6-9E95-A38FA53DA6BB@newclarity.net>
Date: Thu, 10 Oct 2019 13:03:09 -0400
Message-ID: <CAPKYkKy8zDJpvST_YeqmnLBwFeBYcKKZY-nj4KyGKGOdG9XSjw@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ebe2da05949160d9"
Subject: Re: [PHP-DEV] Internals "camps"
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000ebe2da05949160d9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 10, 2019 at 12:11 AM Mike Schinkel <mike@newclarity.net> wrote:

> > I'm not sure where's the log jam here?
>
> The issue is not this specific RFC.
>
> As I wrote earlier, there appear to be heated and non-stop debates over
> (at least) BC, and possibly other areas. People dig in on a position and
> then won't consider any other options that might be available.
>
> > It's a logjam only if somehow we were to imagine more BC
> > breaks, more deprecations and more removal of functionality is somehow
> > vitally necessary for PHP - which decades of thriving without all that
> > amply prove to be false.
>
> Let me restate then, because what was important was not that the word I
> used matched internals@ circumstances exactly, but the fact that there is
> an issue with how the process currently works, as many other people have
> noted already.
>
> We can call it something other than a logjam if it is important to you
> that the word matches.  What about dysfunction instead?
>
> > I don't see what's wrong with just "do not break BC unless you
> > absolutely can't avoid it"... How comes now we have to spend
> > so much time at affirming the obvious?
>
> Frankly I would agree with that, if it were not for a large number of
> people who are actively promoting changes to PHP that would break BC. So
> clearly the current composition of this list includes people who see
> something wrong with the approach you see no reason to question.
>
> Note I am not endorsing their opinion but I am recognizing they have this
> opinion and they are actively trying to change PHP.  So we can embrace
> insanity =E2=80=94 as Einstein would say =E2=80=94 and fight never-ending=
 battles on the
> list, or we can find ways to accommodate everyones needs and wants,
> assuming everyone else is willing to find way to accommodate the needs an=
d
> wants of people that disagree with them.
>
> Looking in from the outside, few people who send emails to this list
> appear to be interested in finding common ground. But maybe if we help
> everyone recognize that nobody wins =E2=80=94 including themselves =E2=80=
=94 when a group
> of people divide up and stake out intransigent and diametrically-opposed
> positions then the list can be a lot more productive.
>
> No single person owns PHP so it is rather ungenerous to adopt a view that
> PHP should conform to any one individual view of the perfect programming
> language.  So what if instead we collectively ask ourselves the question
> "What can I do to meet the other people half way =E2=80=94 in ways that w=
on't
> really cost me all that much =E2=80=94 rather than to maintain an unrelen=
tingly
> rigid posture about the needs and wants of others?"
>
> -Mike
>
>
Mike - I have no issue with compromise when it makes sense. Sometimes,
though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One
side wants to build a 100 yard bridge to an island. The other side doesn't
think we need to build the bridge because we don't need to go to the
island. What's the compromise? Building a 50 yard bridge?

The fact is, when there is a compromise that makes sense, people usually
suggest it. One example being Zeev's proposal on the RFC to raise the error
levels of undefined variables to making it opt-in. Zeev's stance on the
issue was that we shouldn't do anything that was mentioned in the RFC, but,
he felt that a compromise would be to at least make those changes opt-in.
That proposal was rejected by pretty much everyone. That's probably why it
wasn't proposed this time, either.

As for this particular RFC, I think it's a pretty binary decision.
Deprecate them or don't. As long as I've been involved with PHP, nothing is
ever deprecated unless the eventual goal is to remove it. I could be wrong,
and welcome examples where we've deprecated something where the end goal
wasn't removal. Assuming I'm correct though, that provides a pretty strong
reason for why we wouldn't start doing it now.


--=20
Chase Peeler
chasepeeler@gmail.com

--000000000000ebe2da05949160d9--