Re: RFC: Server-Side Request and Response Objects (v2)

From: Date: Mon, 16 Mar 2020 16:04:29 +0000
Subject: Re: RFC: Server-Side Request and Response Objects (v2)
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-109065@lists.php.net to get a copy of this message
Hi all, > On Mar 14, 2020, at 10:18, Rowan Tommins <rowan.collins@gmail.com> wrote: > >> On 13/03/2020 20:36, Larry Garfield wrote: >> >>> * The RFC by design is trying to take the super-globals and make them OOPy; no more, no >>> less. >>> * The super-globals are not based on HTTP. They're based on CGI, which is sort of >>> but not quite an HTTP request. >>> * So... call it CgiRequest/CGIRequest? (I am also ignoring capitalization.) Because >>> that's what it is: It's CGI request data wrapped up into an object, no more, no less. > > This makes a lot of sense to me. I too find this appealing. That prefix would net these class names: - CgiRequest - CgiResponse - CgiResponseSender The only confusion I think might arise is a consumer saying, "I'm not using CGI, I'm using (fcgi|apache|etc)". Turning it over in my mind, I wonder if maybe a Sapi prefix would be a better alternative along this path, especially since these objects relate to the "interface between web server and PHP." <https://www.php.net/manual/en/function.php-sapi-name.php> A Sapi prefix would net us: - SapiRequest - SapiResponse - SapiResponseSender The only obvious objection is that the SAPI list includes 'cli'. While it not strictly outside the realm of the RFC, it certainly is not the focus; but then, tests running at the command line will be under the 'cli' SAPI, so there's at least some sort of rationalization for it. Overall, I think Sapi looks better than Cgi, and certainly better than Server or the other names we've considered. Any further thoughts on naming? > I also just realised that it would make sense to rename $_SERVER in the object, the same way > $_GET has become "query" and $_POST has become "input". Maybe $request->cgi > or something? I sympathize with the desire to rename (or even restructure) the apparent catchall of $_SERVER. But I am still reluctant to do so, especially as no other researched projects use a different name here (whereas some have replaced $_GET with $query, etc). Does anyone besides Rowan long for a different property name here? What are your suggestions, if any? -- 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

« previous php.internals (#109065) next »