Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108523 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 8369 invoked from network); 12 Feb 2020 23:55:37 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Feb 2020 23:55:37 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 08E591804AC for ; Wed, 12 Feb 2020 14:09:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29169 217.70.176.0/20 X-Spam-Virus: No X-Envelope-From: Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 12 Feb 2020 14:09:51 -0800 (PST) X-Originating-IP: 107.223.28.39 Received: from samurai.attlocal.net (107-223-28-39.lightspeed.nsvltn.sbcglobal.net [107.223.28.39]) (Authenticated sender: pmjones@pmjones.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id DB89C40002; Wed, 12 Feb 2020 22:09:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) In-Reply-To: Date: Wed, 12 Feb 2020 16:09:46 -0600 Cc: "Reindl Harald (privat)" , internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> <20200211093357.Horde.rLSaCIKR44fKvPJyltsdQC_@yunosh.horde.org> <3b6074d8-bfd5-41a4-1a86-4ce57f91904d@rhsoft.net> To: Albert Casademont X-Mailer: Apple Mail (2.3608.60.0.2.5) Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2) From: pmjones@pmjones.io ("Paul M. Jones") Hi Albert, > On Feb 11, 2020, at 11:22, Albert Casademont = wrote: >=20 >> Am 11.02.20 um 13:42 schrieb Albert Casademont: >>=20 >>> This is very interesting, thanks! >>>=20 >>> Would it make sense to also add an INI setting to disable = superglobals >>> and response functions? >>=20 >> no because changing basic language behavior that way is not helpful = for >> code meant to run everywhere and not stop working just because = tomorrow >> someone changed a random ini setting >=20 > That could be said for all INI settings: yes they can break things if = you > touch them without knowing what they do. >=20 > I think it might make sense to be able to disable superglobals and = response > functions if your codebase is committed to using the new classes, much = like > the old "register_globals" did. Why pollute the global namespace if = you > don't need them? I share Harald's opinion here. I think a .ini setting to disable = superglobals and the response-related functions is out-of-scope for this = RFC. --=20 Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php