Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

This is only part of a thread. view whole thread
  108737
February 24, 2020 13:57 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
On Wed, 2020-02-12 at 10:54 -0600, Paul M. Jones wrote:
> Hi Johannes, > > > > What indication is there that this will be more successfull than > > the > > filter API? > > Fair question. While I can't say how successful (or not) ext/filter > has been, I *can* say that the proposal does not present > extraordinary or dramatically different ways of working than PHP does > currently. > > The extent of the RFC is only to provide behaviors similar to what > PHP already does, in object-oriented dress. That is, whereas > ext/filter might have been been described as "a new and different way > of working", the concepts and functions in this RFC (even down to the > method and property names!) should be immediately familiar even to > junior PHP developers.
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 ...) (Or we could say filter failed completely and we don'T integrate it and just remove it :-p no idea ...)
> > Also use of $_* is fast to grep for and gives me directly in the > > grep > > an idea about the mess-factor of a code base, tracing all calls to > > a > > member of an instance of a class is harder. (and yes, references > > etc. > > to super globals aren't trivial to trace, but also rare) > > I feel your pain! I do a lot of legacy work too. The `$_` signature > makes grepping easy, so that I can find places where there is spooky- > action-at-a-distace from globally mutable state. > > However, ServerRequest is intended to reduce or remove that globally > mutable state. The $request->get property is readonly, and neither > global nor superglobal. So, while it is tougher to grep for `->get` > and know that you have found a ServerRequest property, the *need* to > do so should be much less even in legacy codebases.
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)
> > Let PHP provide the access to the data and promote the API library > > of the year. > > "API library of the year" -- heh. > > 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.
So it's only "closely" to what users want? So users will still need to wrap it? So purpose is not to make it simpler to use or anything but only to disallow abuses like I mentioned above? I understand why people hate the mutability there, but I think it is a quality of PHP to not stand in the way when crazy things have to be done. And maybe the cases where the mutability can be solved with a FakeServerRequest implementing the same interface easily ... then the question is whether we get users migrated over ... $_GET is in each and every tutorial and code since 2001, when it was introduced in PHP 4.1 .... johannes
  108741
February 24, 2020 17:11 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üter <johannes@schlueters.de> wrote: > > 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 ...)
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 <https://externals.io/message/108436#108507> - "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." <https://externals.io/message/108436#108627> - "[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." <https://externals.io/message/108436#108635>
> (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. >> >> "API library of the year" -- heh. >> >> 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. > > 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. -- 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