Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106978 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 71278 invoked from network); 12 Sep 2019 18:43:04 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 12 Sep 2019 18:43:04 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 285152D1FA8 for ; Thu, 12 Sep 2019 09:19:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Thu, 12 Sep 2019 09:18:56 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id t84so17615524oih.10 for ; Thu, 12 Sep 2019 09:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=THrArB4BGkAOWoTX3EGIbypA5bUGP3XHV+yTcp9mTF4=; b=YRo94HNS9TfKgKj/0wf4Z2qX+isaHYc25pSk8tr9gwPQDVXFTB/kS9kUgItwr7DtQ6 OppvWXjHMPzF6YAmuwZ+fIqWVhVcObCX1hI8tmvnulcohwqDlbKR2am4l5YlXcojfRJ2 s83C07Vx6wCBi1aZg745OynszblSGuVKsIR+mPqGm1cnsUtl3tm3MvghuZdohsAI9v6q 5mhgnnXBd8ATrrJmK43EluAp34LcugVOLTi6Z7Ma+2bJXuQ2QQ9fxQzdKpRLBe0/PdpX ex93mT1ls47Vy6L8XcImllHJ4PgnpJRucMOigoav6Ui+FExKPV0HW9MQmx3W4ThOaWc6 EBBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=THrArB4BGkAOWoTX3EGIbypA5bUGP3XHV+yTcp9mTF4=; b=PBOEju+TayafOtMaf+RC5DDSPHV2LNsuYCwzmsQQSauUsSNWoEz+R/woGwoMy1wG8C e4RNNvTaDDRBhmi/qiraGIxPu8Lft7MU/vHcz5ARtNm0moTj8pJIMdUaf/RGszYx9IVp SKFBxtkqFTLMmv9ayeds2BIRhZDP7uUqNAJ6hqa6PPh9GaQH90HKIH++L3+XvIF9XUMB eQBVYJ8Nf8g4lXAFFShn8By36LEkVnMVJJ8WKNrElVmwyhWOKZdoItBjYeI3jWIFIt81 YL6C5p5jy428vMyL6v0DlBm3B1G8eBmPUcR42kSUno1tsmhS+59iLQwLWVksEcUt0+cI eP9Q== X-Gm-Message-State: APjAAAXpawZrKZ2qG9wX4wuXHlw3Bic4eldb/lK4kZwbHs5QN1mrT7hq xMEqeJr01FuMPKrHwxECOBFYU7URlrqMmNanEdA= X-Google-Smtp-Source: APXvYqzjdJ+FsDpJ+WKLeFw7bkt8zdFZba7ep4nuLMPQMJL5anTYmwKiKcxEgY8JVF3edQXKDhJ4RjCbDJoVtal2oUI= X-Received: by 2002:aca:fdc9:: with SMTP id b192mr889686oii.50.1568305135899; Thu, 12 Sep 2019 09:18:55 -0700 (PDT) MIME-Version: 1.0 References: <076701d56978$86020910$92061b30$@php.net> <078e01d5697c$5512bc10$ff383430$@php.net> In-Reply-To: <078e01d5697c$5512bc10$ff383430$@php.net> Date: Thu, 12 Sep 2019 12:18:19 -0400 Message-ID: To: Zeev Suraski Cc: Marco Pivetta , PHP Internals List Content-Type: multipart/alternative; boundary="00000000000086641705925d7ef3" X-Envelope-From: Subject: Re: [PHP-DEV] Changing fundamental language behaviors From: morganbreden@gmail.com (Morgan Breden) --00000000000086641705925d7ef3 Content-Type: text/plain; charset="UTF-8" > 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. [...] > 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. [...] > 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, "strictly inappropriate and out of the question" seems like a statement of opinion to me. While I personally agree with your standpoint on changing this fundamental behavior, your response here seems out of left field. Furthermore, statements like "we do not get to deprecate or radically change them" and "this is simply not going to happen" are a wholly inappropriate response to *any* effort. I respect your vast contributions to the language and your (usually) level-headed stances on this mailing list, but you are not the grand czar of PHP and I don't believe that hard line is yours to make. Declaring such a thing reads to me like a spit in the face of everyone who contributes to the language and to the concept of a community-driven open source project to begin with. Over the past few years the movement to push PHP into more modern concepts has explosively grown in popularity and your resistance to the more rapid and drastic portions of it is understandable, if nothing else. However, using your bully pulpit to insist that things you don't like can't be done leaves a very sour taste in my mouth. If such limits exist, they should be clear and codified - not something that exists in the mind of you and whoever else only to be brought up when someone wants to breach them. On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski wrote: > > > > -----Original Message----- > > From: Marco Pivetta > > Sent: Thursday, September 12, 2019 5:59 PM > > To: Zeev Suraski > > Cc: PHP Internals List > > 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 > > --00000000000086641705925d7ef3--