On Fri, Mar 13, 2020, at 9:55 AM, Paul M. Jones wrote:
> > As with anything any of us has written, I’m not 100% sold on
> > ‘Current{Request,Response}` even after writing it, but I think it’s at
> > least a little more specific about what they do, when the namespace is
> > taken into account.
>
> `Current{...}` is not something we had previously considered; that
> would net us, in the global namespace:
>
> - CurrentRequest
> - CurrentResponse
> - CurrentResponseSender
>
> I will need to ponder on those as well.
>
> Any further thoughts or opinions on this, Stephen? Or from anyone else?
I am still negative on the RFC overall, but I'll throw this out there:
* 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.
(The fact that it is no more is the reason I'm not a fan, but at least then
it's accurate as to what it is, and isn't, and doesn't namespace clobber those
libraries that are modeling HTTP, rather than CGI.)
The response object is less CGI-bound, so it could still be ServerResponse
since it's a response from a server, and not intended for any other uses (like
HTTP client libraries).
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
