Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107473
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>
 <CAPKYkKy8zDJpvST_YeqmnLBwFeBYcKKZY-nj4KyGKGOdG9XSjw@mail.gmail.com>
In-Reply-To: <CAPKYkKy8zDJpvST_YeqmnLBwFeBYcKKZY-nj4KyGKGOdG9XSjw@mail.gmail.com>
Reply-To: bishop@php.net
Date: Thu, 10 Oct 2019 13:14:41 -0400
Message-ID: <CAEYWF=7rTHdjaJTtnXVYts-xuhyOJ5OpHiWMnBUu1nhcrzDATQ@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Mike Schinkel <mike@newclarity.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004cd5db0594918a07"
Subject: Re: [PHP-DEV] Internals "camps"
From: bishop@php.net (Bishop Bettini)

--0000000000004cd5db0594918a07
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 10, 2019, 13:03 Chase Peeler <chasepeeler@gmail.com> wrote:

> 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 an=
d
> > 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 someho=
w
> > > vitally necessary for PHP - which decades of thriving without all tha=
t
> > > 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 hav=
e
> > 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. S=
o
> > 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 th=
is
> > 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-endi=
ng 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
> and
> > 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-oppose=
d
> > positions then the list can be a lot more productive.
> >
> > No single person owns PHP so it is rather ungenerous to adopt a view th=
at
> > PHP should conform to any one individual view of the perfect programmin=
g
> > language.  So what if instead we collectively ask ourselves the questio=
n
> > "What can I do to meet the other people half way =E2=80=94 in ways that=
 won't
> > really cost me all that much =E2=80=94 rather than to maintain an unrel=
entingly
> > 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. O=
ne
> 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?
>

No. The compromise is funding a ferry system. Or laying Internet between
them. Or a passenger pigeon mail route.

Sometimes compromise requires deep discussion about the motivations for
each side and coming to a lateral, mutually acceptable, solution.

But we'd rather not discuss motivations and just bicker about the surface
results. I.e., argue the X, rather than the Y, of these little XY problems
we're solving.



> 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 err=
or
> 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, bu=
t,
> 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 i=
t
> 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 wron=
g,
> and welcome examples where we've deprecated something where the end goal
> wasn't removal. Assuming I'm correct though, that provides a pretty stron=
g
> reason for why we wouldn't start doing it now.
>

Short tags are deprecated, per the manual. They are not planned to be
removed and, per the vote discussions and margins, probably won't ever go.

>

--0000000000004cd5db0594918a07--