On Fri, Oct 31, 2014 at 12:04 PM, Andrea Faulds <a...@ajf.me> wrote: > > > > So there’s still a default implementation, then? So, if you want to parse > in userland, how does that work? The default implementation fills in the > variables and then your implementation parses it again, wasting CPU time > and making the request take longer? Or does the default implementation do > nothing at all unless asked to, breaking existing apps unless they’re > modified to request parsing? Or is it INI-determined?? >
No, by overriding the parseBody or parseParameters methods, for example, you can prevent the default behavior from happening. (i.e. it is not doing the same thing twice). Simply by extending the HttpRequest class, we can call on the child class instead. Any methods not implemented in the extending class would be forwarded to the parent class as per normal PHP inheritance rules. > > > OK. So they’re just interfaces, then? In which case, why not leave the > PHP-FIG to finish its HTTP Message proposal instead? > > > *snip* > So, all you’re proposing is a set of interfaces, to compete with the work > the PHP-FIG is doing. > > I don’t see how this is useful. How, exactly, does adding interfaces solve > the problems with superglobals? Because you’re creating a common standard > for alternative request implementations? But, we already have such a WIP > standard in userland from the PSR people. > > I really don’t get this RFC. If this was to add implementations of the PSR > Request/Response stuff, that might be useful. But merely adding new > interfaces… I don’t get it. Why duplicate effort? How does this fix > superglobals? > > Competing ideas are good and the very reason that drives innovation. This proposal is for both the interface and the implementing class, which can be extended to create custom behavior in handling the HTTP request/response. I have no idea why you think PHP-FIG or PSR is involved in this conversation. This is a PHP internals matter and should be considered for PHP internals purposes. The benefits and cons of this proposal are pretty clear, I think. You get the ability to handle different kinds of requests as you see fit or you leave the default behavior intact and everyone wins. The only thing you don't get if you do this in userland instead, is you have to do the parsing of the message twice, which this RFC attempts to circumvent, but offering a way to overrride the parser before parsing takes place (if you choose to implement it).
