> On Oct 30, 2014, at 4:15 PM, Andrea Faulds <a...@ajf.me> wrote: > > >> On 30 Oct 2014, at 20:49, Sherif Ramadan <theanomaly...@gmail.com> wrote: >> >> 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. > > You know, before I keep up this discussion, it’d be nice if you clarified > what, exactly, you are proposing. The RFC contains no detail at all. I really > haven’t the faintest. > > Also, removing $_GET and $_POST is a *massive* backwards-compatibility break. > I would vote against this proposal and I hope everyone else will join me in > doing so, for that reason alone. > > Please, don’t completely break every single PHP site I’ve ever written. :( > >> So the fix to something like PUT/DELETE requests is to add yet another super >> global. > > No, not really. $_PUT and $_DELETE don’t really make sense, why are you > sending form data to PUT or DELETE? Populating $_POST also makes sense, it’s > not a POST request. The answer is just to add a function to do multipart > parsing, to expose PHP’s current parser, which satisfies the obscure use case > of needing form data parsing for PUT and DELETE. I don’t think this would be > too hard to do.
It's not hard. Again, pecl/http v2 proposal will give core everything it needs. I honestly don't know why this is being discussed any further when theirs a solution that gives functionality requested here and contains zero BC breaks. > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
