On Fri, Oct 31, 2014 at 5:25 AM, Andrea Faulds <a...@ajf.me> wrote: > > > This is no less of a backwards-compatibility headache. This still breaks > every PHP app I have ever written. > > To be perfectly clear, the default behavior would remain the same, so no PHP app you have ever written would break. The difference is, you would now be able to override any part of the default behavior by extending the HttpRequest class in your own code.
> > > No no, I'm not concerned about the contents of the interface. I'm > wondering what, exactly, this "interface" does? I don't see how a mere > interface would replace the superglobals, unless you want a superglobal > request object that anyone can swap out, which sounds like a bad idea. > > The interfaces do exactly what you see here. They specified which methods the HttpRequest and HttpResponse objects must implement. If you bothered to invest nearly as much time in reading the updates to the RFC as you did to making blanket statements and objections, you might actually find less reason to respond with objections so abruptly. The HttpRequest and HttpResponse classes are intended to provide a central place for message handling behaviors and their properties can be used to describe these behaviors. So, if you wanted to support a $_PUT superglobal, rather than adding one to the language, you can simply add the behavior to do the processing of PUT requests in your HttpRequest class, by extending HttpRequest and defining how PUT variables are handled there. > -- > Andrea Faulds > http://ajf.me/ >
