On Thu, Oct 30, 2014 at 4:24 PM, Andrea Faulds <a...@ajf.me> wrote: > > > On 30 Oct 2014, at 19:49, Sherif Ramadan <theanomaly...@gmail.com> > wrote: > > > > Well, let's look at how well providing implementation has worked out for > > PHP so far. > > > > GPC variables are implementation. They pose rigidity to userland code > for a > > number of reasons. For example, if you do send a PUT request to PHP, PHP > > will not bother populating GPC at all. Instead it leaves the user to > define > > their own handling from the input stream directly. If you do send > GET/POST > > requests to PHP, the variable names can be mangled and $_GET/$_POST are > > treated differently for encoding as one is run through url_decode and the > > other is not. > > We could just fix these problems rather than adding an entirely new > implementation. >
Yes, this proposal is intended to do two things. 1) Fix the aforementioned problems. 2) Improve upon the capabilities of PHP's request handling for future use cases through a unified interface. To say that this proposal and fixing the aforementioned problems are two distinct options (as in we can either fix these problems or go with this proposal) is a very reductive form of thinking in which the only outcome favors one party or the other. My proposal is intended to result in a win-win situation where everyone involved can be satisfied, not an ultimatum. If you consider all of the major existing PHP frameworks today there is always some form of HttpRequest class handling these things and almost all of them do it slightly differently. What's worse, is they are all very inefficient implementations that I believe can be done far more efficiently in php-src. A lost of them are also unnecessarily complex. I think all of this can be simplified if the interface is just laid out in a straight-forward manner and then userland implementations will find less and less reason to over-engineer the implementation. > -- > Andrea Faulds > http://ajf.me/ > > > > >
