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 pmjo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
