Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

This is only part of a thread. view whole thread
  108440
February 10, 2020 20:44 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
Hi,

On Mon, 2020-02-10 at 10:18 -0600, Paul M. Jones wrote:
> 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
What indication is there that this will be more successfull than the filter API? The filter API was our previous attempt to improve upon input handling. With this new API we have three major ways (superglobals, filter, new API) Historically PHP isn't really successful in providing higher level APIs to things and I think leaving this to userland is very viable, since composer and performance improvements in later PHP 5 and PHP 7. Also use of $_* is fast to grep for and gives me directly in the grep an idea about the mess-factor of a code base, tracing all calls to a member of an instance of a class is harder. (and yes, references etc. to super globals aren't trivial to trace, but also rare) Let PHP provide the access to the data and promote the API library of the year. johannes
  108510
February 12, 2020 16:54 pmjones@pmjones.io ("Paul M. Jones")
Hi Johannes,


> What indication is there that this will be more successfull than the > filter API?
Fair question. While I can't say how successful (or not) ext/filter has been, I *can* say that the proposal does not present extraordinary or dramatically different ways of working than PHP does currently. The extent of the RFC is only to provide behaviors similar to what PHP already does, in object-oriented dress. That is, whereas ext/filter might have been been described as "a new and different way of working", the concepts and functions in this RFC (even down to the method and property names!) should be immediately familiar even to junior PHP developers.
> Historically PHP isn't really successful in providing higher level APIs > to things and I think leaving this to userland is very viable, since > composer and performance improvements in later PHP 5 and PHP 7.
I addressed the "userland" argument in my response to Mark Randall; please forgive me for not repeating it here.
> Also use of $_* is fast to grep for and gives me directly in the grep > an idea about the mess-factor of a code base, tracing all calls to a > member of an instance of a class is harder. (and yes, references etc. > to super globals aren't trivial to trace, but also rare)
I feel your pain! I do a lot of legacy work too. The `$_` signature makes grepping easy, so that I can find places where there is spooky-action-at-a-distace from globally mutable state. However, ServerRequest is intended to reduce or remove that globally mutable state. The $request->get property is readonly, and neither global nor superglobal. So, while it is tougher to grep for `->get` and know that you have found a ServerRequest property, the *need* to do so should be much less even in legacy codebases.
> Let PHP provide the access to the data and promote the API library of the year.
"API library of the year" -- heh. To be fair, though, the API presented by ServerRequest and ServerResponse is highly similar to that presented by PHP itself; far from being "API of the year" it honors existing PHP functionality quite closely. -- 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