Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106982
MIME-Version: 1.0
References: <076701d56978$86020910$92061b30$@php.net> <CADyq6sK4HektgfDpCCFR3=bumyPaf9vn=-WdvaboHybBQKd53g@mail.gmail.com>
 <078e01d5697c$5512bc10$ff383430$@php.net> <CAKws9z1EBSqCFy2wD3cEV49KDSJOd6tT04PrCkxG8+3Hb6WpTA@mail.gmail.com>
 <CAPKYkKw1EU3Qp6W7b19r4kMKPD1HntH+7NQSxSiDNcLXqPERMA@mail.gmail.com>
In-Reply-To: <CAPKYkKw1EU3Qp6W7b19r4kMKPD1HntH+7NQSxSiDNcLXqPERMA@mail.gmail.com>
Date: Thu, 12 Sep 2019 13:02:56 -0400
Message-ID: <CAKws9z3ns38J7aCixr3P4uuQHwdVpowhbikVixQKBPLNerqX6Q@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Zeev Suraski <zeev@php.net>, 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)

Apologies for my semantic imprecision. I hope the intent of my email
remains clear.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

On Thu, Sep 12, 2019 at 12:56 PM Chase Peeler <chasepeeler@gmail.com> wrote=
:
>
>
>
> On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski <scott@paragonie.com> =
wrote:
>>
>> 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=
. We can tweak them, we can augment them - we do not get to deprecate or ra=
dically 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.)
>>
>
> Don't use the term "deprecations and removals" - it's not the right term =
here. There are many deprecations and removals that don't fundamentally cha=
nge the language. For example, deprecating create_function() after closure =
support was added didn't fundamentally change the language.
>
>>
>> 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 inap=
propriate.
>> >
>> > No Marco.  The RFC process wasn't meant to deal with who has authorita=
tive say any more than it was meant to deal with changing fundamental behav=
iors in PHP.  The fact we got used to putting everything to a vote doesn't =
mean that it can work for anything and everything.
>> >
>> > While I realize my email is unpleasant for many to read, it's in the c=
ontext of an RFC that attempts to do something that is strictly inappropria=
te and out of the question.  Stating the fact, that the RFC process was nev=
er 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 a=
nd stick to it.  I know how much fire that's going to draw and I know I'd h=
ate 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 t=
o stay.  We can tweak them, we can augment them - we do not get to deprecat=
e or 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 strict=
er 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
>> >
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> --
> Chase Peeler
> chasepeeler@gmail.com