Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
  106982
September 12, 2019 17:02 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 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