> On Feb 10, 2020, at 11:18 AM, Paul M. Jones <pmjo...@pmjones.io> wrote:
>
> Hi Internals,
>
> After a couple of years of incubation, I am happy to offer a second version
> of this RFC:
>
> https://wiki.php.net/rfc/request_response
>
> It proposes an object-oriented approach around request and response
> functionality already existing in PHP, in order to reduce the global-state
> problems that come with superglobals and the various response-related
> functions.
>
> The SQLite "about" page says, "Think of SQLite not as a replacement for
> Oracle but as a replacement for fopen()." <https://www.sqlite.org/about.html>
> Likewise, think of this RFC not as a replacement for HttpFoundation or
> PSR-7, or as a model of HTTP messages, but as an object-oriented alternative
> to superglobals, header(), setcookie(), setrawcookie(), and so on.
>
> Thanks in advance for your time and consideration while evaluating it.
I like this, a lot.
Having a language _standard_ approach means that I could depend on it existing
and that all (new) userland code I might want to incorporate into a project
would be compatible rather than the current state of 100! different
incompatible implementations across frameworks.
I had numerous questions and concerns, but after reading through the RFC and
the associated links I think you addressed most of them.
I do have questions about ServerResponse. It is not clear how that interacts
with existing echo, header(), setcookie(), etc? You say it creates a buffer;
is $responseSender->send($response) effectively the same as having issued
regular echo, header(), setcookie(), etc. all at once? And that there is no
global buffer but instead the application would have to manage using a shared
$response on its own because each instance of $response has it's own buffer and
can be sent at any time into the existing output "stream?"
Regarding ServerRequest I saw the comment about using a factory instead of
creating an instance and your reason for not going that route. How about
instead creating an empty mutable object with the constructor and then a method
with an optional array parameter that adds the values and "locks" it to be
mutable, i.e.
$request = new ServerRequest();
$request->initialize();
// OR
$request->initialize([
'_SERVER' => [
'foo' => 'bar',
],
]);
With this approach someone could create a class that contains the ServerRequest
and build the object up to be anything they like which could be useful for
testing, i.e.
$request = new ServerRequest();
$request->get = [ 'foo' => 'bar' ];
$request->cookie = [ 'id' => 123 ];
$request->nv = $_ENV;
$request->server = $_SERVER;
$request->lock();
I would also suggest considering to add get(), post(), request(), cookie(),
server() and end() methods to ServerRequest that would incorporate the
functionality of filter_input(). Otherwise we have to bypass the objects to
get filtering.
In general I think this would definitely be a nice enhancement to PHP, IMO. It
would be great to be able to deprecate use of $GLOBALS, etc. with a language
_standard_ approach, and flag their use as problematic in any of our code.
Would you not also add an option to generate a warning when using them for
those who want to deprecate their use in their own code (deprecating across the
board would be too extreme give how much CMS and framework code uses them
intimately.)
Thanks in advance for considering.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
