> On Feb 12, 2020, at 1:20 PM, Niklas Keller <m...@kelunik.com> wrote: > I think the request / response API is entirely fine being solved in > userland instead of in php-src.
I want to disagree in support of this RFC. While is *has* been solved in userland, but it has been solved 25+ times in 25+ different incompatible ways. This RFC would allow for a *single* solution that is compatible across all frameworks, and frameworks could create a shim to support their existing implementations. And given that it would be in core vs. userland, this would *not* apply: https://xkcd.com/927/ The one concern should be if there is anything about this RFC that would make writing such a shim impossible for any framework vendor? > I think we shouldn't take over the naming of the super globals, e.g. > $_GET really contains the query parameters and has nothing to do with > GET or POST, so $request->getQueryParameter(...) would be a better > name. Please no. That is all too Java-esque verbosity. Very commonly used functionality can afford to be concise like $request->get() because it would be well-known and not have to compete with lots of other functionality for mindshare. Thus no need for this to be so precise and have such long names when everyone writing PHP would soon lean what it means. > I don't see any reason to keep specials such as > $_SERVER['HTTP_X_REQUESTED_WITH'] vs. $request->requestedWith, which > is just another HTTP header. Reason: $request->requestedWith can be type-safe, something you asked for in another context. $_SERVER['HTTP_X_REQUESTED_WITH'] cannot be type safe without special cases in the language. > The Request object should be mutable, e.g. you might want to change > the client IP to be based on a x-forwarded-header instead of the TCP > source address. I totally agree it needs to be mutable, but only prior to first use. After the first use having it be locked would gain us the benefits of robustness that immutability can provide. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
