On Thu, Oct 30, 2014 at 4:42 PM, Andrea Faulds <a...@ajf.me> wrote: > > > On 30 Oct 2014, at 20:33, Sherif Ramadan <theanomaly...@gmail.com> > wrote: > > > > Yes, this proposal is intended to do two things. 1) Fix the > aforementioned problems. > > By the sounds of things, it doesn’t fix these problems, it just adds a new > interface which lacks them. That’s not the same thing. > > No, the interface makes it possible to implement your own behavior, but it does not prevent PHP from implementing default behavior. In that PHP would implement its own HttpRequest class, for example, which the user can then extend to override default behavior or modify it as they see fit for their particular use case. This is much like the Session interface, which makes it possible to change session storage mechanisms in userland, but still have a confirming method of session handling in PHP.
> > 2) Improve upon the capabilities of PHP's request handling for future > use cases through a unified interface. > > What unified interface? You’re allowing anyone and everyone to implement > their own request handling. > Yes, by allowing this you make it extensible. However, having the interface is what makes it possible to unify the efforts of dealing with the HTTP messages both in userland and in PHP internals. > > > 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. > > The only reason an implementation of HttpRequest would be inefficient is > because it has to work-around problems with $_GET and $_POST. Problems we > could simply fix. > So the fix to something like PUT/DELETE requests is to add yet another superglobal. However, this is still a very rigid fix that requires continuous maintenance and fulfilling feature requests on the part of internals. Think of implementing a new session handler for every session storage mechanism in PHP. This is a lot of unneeded effort when we can just expose the session interface to userland and make it extensible by nature. The alternative is far more useful and less closed up (preventing future problems to fix). Let's not also ignore the fact that such features have been forsaken by PHP internals for years. I have bug reports dating back to 2010 that have asked for such features that have long been unanswered. So the current desire to fix anything along these lines appears to be minimal, if not non-existent, right now. > > -- > Andrea Faulds > http://ajf.me/ > > > > >
