On Wed, 2020-02-12 at 10:54 -0600, Paul M. Jones wrote: > 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.
Is there a way to integrate filter, so we can reduce (over the long term) the interfaces and get to a single one (getting rid of register_globals took almost to the day 10 years from creating super globals, via deprecation and changed default to removal, so I'm not asking for the unity tomorrow but having a plan ...) (Or we could say filter failed completely and we don'T integrate it and just remove it :-p no idea ...) > > 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. As a side note: I love the fact that the low layer is mutable. It allows me to take legacy code and wrap it in a more modern framework and fake the old environment as a migration strategy (one has to be aware this produced debt and needs a plan to get rid of that, but can be practical for a migration rather than rewrite, also useful for testing bad code to allow cleanup) > > 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. So it's only "closely" to what users want? So users will still need to wrap it? So purpose is not to make it simpler to use or anything but only to disallow abuses like I mentioned above? I understand why people hate the mutability there, but I think it is a quality of PHP to not stand in the way when crazy things have to be done. And maybe the cases where the mutability can be solved with a FakeServerRequest implementing the same interface easily ... then the question is whether we get users migrated over ... $_GET is in each and every tutorial and code since 2001, when it was introduced in PHP 4.1 ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
