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 <johan...@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 pmjo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
