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 radically > 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 <z...@php.net> wrote: > > > > > -----Original Message----- > > From: Marco Pivetta <ocram...@gmail.com> > > Sent: Thursday, September 12, 2019 5:59 PM > > To: Zeev Suraski <z...@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 > > inappropriate. > > No Marco. The RFC process wasn't meant to deal with who has authoritative > say any more than it was meant to deal with changing fundamental behaviors 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 context > 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 > stay. We can tweak them, we can augment them - we do not get to deprecate 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 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
