Re: Changing fundamental language behaviors

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 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.) >> > > 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 change 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 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 >> > > > -- > Chase Peeler > chasepeeler@gmail.com