> On Mar 16, 2020, at 12:04 PM, Paul M. Jones <pmjo...@pmjones.io> wrote: > > 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?
That works well IMO. >> 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? I don't think this is important anymore if we call it Sapi or CGI. It was only an issue IMO if if we were still wanting to call it Request. But again, just my opinion. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
