On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski <sc...@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 <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 > > -- Chase Peeler chasepee...@gmail.com
