Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108741 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 58237 invoked from network); 24 Feb 2020 18:54:24 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Feb 2020 18:54:24 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BF9B61801FD for ; Mon, 24 Feb 2020 09:11:32 -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, 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 relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (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 ; Mon, 24 Feb 2020 09:11:30 -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 relay6-d.mail.gandi.net (Postfix) with ESMTPSA id D467EC0009; Mon, 24 Feb 2020 17:11:28 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) In-Reply-To: <7eecdcc9e85b338f9869b4037647db63279c97e3.camel@schlueters.de> Date: Mon, 24 Feb 2020 11:11:27 -0600 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> <5500e8e70ed1cdc162e5848b8959c63d8adc4853.camel@schlueters.de> <6EE2BBA9-882A-4879-A6E7-E3262DD88B75@pmjones.io> <7eecdcc9e85b338f9869b4037647db63279c97e3.camel@schlueters.de> To: =?utf-8?Q?Johannes_Schl=C3=BCter?= 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 Johannes, Thanks for continuing to evaluate the proposal. Am I correct in thinking that your primary objection to ServerRequest is = that it is read-only? If so, do you have other objections beyond that? = And if not, please correct me. Meanwhile, to respond to your comments ... * * * > On Feb 24, 2020, at 07:57, Johannes Schl=C3=BCter = wrote: >=20 > Is there a way to integrate filter, so we can reduce (over the long > term) the interfaces and get to a single one (getting rid of > register_globals took almost to the day 10 years from creating super > globals, via deprecation and changed default to removal, so I'm not > asking for the unity tomorrow but having a plan ...)=20 My position is that integrating the filter extension is out-of-scope for = this RFC. To sum up prior conversation: - Anyone using ext/filter can still do so, just via filter_var() on a = ServerRequest property, instead of via filter_input() on the = superglobals directly - "I think you [Mike] are over-estimating how central the filter API is = to most people's workflow with requests. I think that's partly because = designing a good validation API is hard, but also because filter_input in = particular is a combination of three different concerns." = - "[T]rying to build a single set of classes which include a system for = getting global state AND a system for parsing it in different ways AND = an in-built validation API seems like a mammoth task. And if you keep it = monolithic, any feature you miss or make a mistake on is much harder to = fix later." > (Or we could say filter failed completely and we don'T integrate it = and > just remove it :-p no idea ...) I have no opinion on whether ext/filter has "failed" or not. While I = don't see it everywhere all the time, I do see it occasionally; that = occasional use is in domain-level work, using filter_var() on properties = and parameters, rather than using filter_input(). > As a side note: I love the fact that the low layer is mutable. It > allows me to take legacy code and wrap it in a more modern framework > and fake the old environment as a migration strategy (one has to be > aware this produced debt and needs a plan to get rid of that, but can > be practical for a migration rather than rewrite, also useful for > testing bad code to allow cleanup) I'm a fan as well; I don't imagine that I would want the superglobals = themselves to be made read-only. However, I *do* think that once they pass a certain boundary, they = should no longer be mutable. In general, I think that boundary is at the = router or other front controller system. The ServerRequest object exists for working at or beyond that boundary; = i.e., once you have gotten the superglobals into the state you want, = copy them them into a ServerRequest object and pass *that* object = around, instead of reading from and writing to the superglobals = themselves. >>> Let PHP provide the access to the data and promote the API library >>> of the year. >>=20 >> "API library of the year" -- heh. >>=20 >> To be fair, though, the API presented by ServerRequest and >> ServerResponse is highly similar to that presented by PHP itself; far >> from being "API of the year" it honors existing PHP functionality >> quite closely. >=20 > So it's only "closely" to what users want? That's not quite what I said. ;-) To reiterate, what it "closely" does is "honor existing PHP = functionality." For example: - instead of reading from `$_SERVER`, read from `$request->server` - instead of calling `header("Foo: bar")`, call = `$response->setHeader("Foo", "bar")` - instead of calling `setcookie("baz", "dib")`, call = `$response->setCookie("baz", "dib")` That is, it's not a big jump from using the superglobals and functions, = to using the object properties and methods. Making the two ways of = working very close to each other is a goal of the RFC. > So users will still need to wrap it? I wouldn't think they "need" to wrap it, unless they want it to do = something it does not already do. I suspect that some will find it = satisfactory as-is, and that others will want to add custom = functionality. > So purpose is not to make it simpler to use or anything but only to = disallow abuses like I mentioned above? The purpose is as stated in the RFC: that is, to provide a more = "object-oriented approach around request and response functionality = already existing in PHP, in order to reduce the global mutable state = problems that come with superglobals and the various response-related = functions." So it's not that the RFC proposes a "simpler" way to use the = superglobals and response-related functions -- it's that the RFC makes = it *possible* to address them in a more object-oriented way, while = separating them from global mutable state. --=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