Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106980
MIME-Version: 1.0
References: <076701d56978$86020910$92061b30$@php.net> <CADyq6sK4HektgfDpCCFR3=bumyPaf9vn=-WdvaboHybBQKd53g@mail.gmail.com>
 <078e01d5697c$5512bc10$ff383430$@php.net>
In-Reply-To: <078e01d5697c$5512bc10$ff383430$@php.net>
Date: Thu, 12 Sep 2019 12:51:33 -0400
Message-ID: <CAKws9z1EBSqCFy2wD3cEV49KDSJOd6tT04PrCkxG8+3Hb6WpTA@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Marco Pivetta <ocramius@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: scott@paragonie.com (Scott Arciszewski)

I'd like to weigh in as a voice of reason here.

> There are no processes to make fundamental non-opt-in language changes in=
 PHP.

This part might be reasonable.

> There won't be such processes either. These behaviors are here to stay. W=
e can tweak them, we can augment them - we do not get to deprecate or radic=
ally change them.

This part is totally unreasonable.

Let me explain:

"We lack a process" opens a door. If the RFC process is inadequate to
address necessary deprecations and removals, then what process *would*
be adequate and appropriate?

THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe
contrary to Zeev about whether the RFC process is adequate and
appropriate.

"There won't be such processes either" shuts the just-opened door in
the rudest manner possible. This doesn't lead to a productive
conversation, this just ends it with Zeev's opinion being final.

My thoughts:

I think we should give Zeev precisely half of what he wants here:
Let's discuss whether a separate process should be created for
deprecations/removals... and if so, what it would look like. And then
if we come up with something new, in true Internals fashion, create an
RFC and vote on our new addition to the RFC process. (Even Zeev has to
acknowledge that additions are fine, with 2/3 majority.)

But we shouldn't accept his door-shutting terms just because he says so.

Respectfully,

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises


On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski <zeev@php.net> wrote:
>
>
>
> > -----Original Message-----
> > From: Marco Pivetta <ocramius@gmail.com>
> > Sent: Thursday, September 12, 2019 5:59 PM
> > To: Zeev Suraski <zeev@php.net>
> > Cc: PHP Internals List <internals@lists.php.net>
> > Subject: Re: [PHP-DEV] Changing fundamental language behaviors
> >
> > If you want to have an authoritative say on what the RFC process is for=
 or not,
> > please start a new RFC about it: your mail is just straight out inappro=
priate.
>
> No Marco.  The RFC process wasn't meant to deal with who has authoritativ=
e say any more than it was meant to deal with changing fundamental behavior=
s in PHP.  The fact we got used to putting everything to a vote doesn't mea=
n that it can work for anything and everything.
>
> While I realize my email is unpleasant for many to read, it's in the cont=
ext of an RFC that attempts to do something that is strictly inappropriate =
and out of the question.  Stating the fact, that the RFC process was never =
meant to allow this to be done, is a statement of fact.
>
> I *hate* to be in the position to be the one who has to point it out and =
stick to it.  I know how much fire that's going to draw and I know I'd hate=
 every second of it.  But it is what it is.
>
> There are no processes to make fundamental non-opt-in language changes in=
 PHP.  There won't be such processes either.  These behaviors are here to s=
tay.  We can tweak them, we can augment them - we do not get to deprecate o=
r radically change them.
>
> We can (and I believe should) augment them with alternative, stricter opt=
-in behaviors.  But those who dream of simply changing PHP into a stricter =
language step by step should understand that this is simply not going to be=
 happen.  Not now, not ever.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>