Re: Changing fundamental language behaviors

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 <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 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 >