On 14 Oct 2014, at 14:42, Kris Craig <kris.cr...@gmail.com> wrote: > I don't think that would be a good idea, either. They require more typing > and it'd probably be a lot easier for devs to remember which one means GET > and which one means POST.
I’ve already proposed the shorter $_QUERY and $_BODY. > PHP is supposed to be KISS, right? Well, the current reliance on > php://input for two methods but not the other two invites confusion. That > makes it less-than simple, I believe. > > Removing or renaming $_GET and $_POST would also create confusion and > almost certainly cause widespread BC breakage on a pretty massive scale. I never said anything about removing $_GET or $_POST. I suggested adding saner aliases. > And there's really no gain to offset that. So that just leaves us with > either continuing to have two REST methods but not the others or add a > $_PUT and a $_DELETE, even if they just alias to php://input again. Adding $_PUT and $_DELETE is silly. We already have a nonsensical system where $_GET isn’t about GET, but about query string parameters, and $_POST isn’t about POST, but the request body. We should create sane aliases ($_QUERY and $_BODY) and extend $_POST/$_BODY to support request bodies from any method. This would make things actually simpler, and less confusing, as we stop pretending $_GET is about GET and $_POST is about POST. By using $_QUERY, it’s clear it’s about query string parameters, which any method can have. Similarly, by using $_BODY, it’s clear it’s about request body parameters, which any method can also have. Sure, all existing code uses $_GET and $_POST and they won’t go away any time soon. But we would have saner names that people writing new code can use. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
