Hi, If it were me, I'd rather delete all the superglobals. It's a horrible API, I don't think anyone can deny that. Now of course, it'd break a tons of code, so I don't suggest to actually delete it.
However, instead of trying to work around current superglobals and trying to provide meaningful names, how about actually trying to provide a correct API? I won't suggest a Request class, because such an interface is best left to userland imho. However, I'd like to propose such an API: request_get(): gets a request array/object. It only has the unparsed request headers. request_cookie_parse(): parses the requests cookie header in an array similar to $_COOKIE. $_COOKIE could use this new function to build its array. request_cookie_get($name): gets the value of $name in the cookie. Calls request_cookie_parse() if it hasn't been called before. request_urlencoded_body_parse(): parses an urlencoded body. It'd give an array similar to $_POST. request_urlencoded_body_get($name): gets the value of $name in the parsed urlencoded body. Calls request_urlencoded_body_parse() if it hasn't been done before. request_query_string_parse(): parses the query strings of a request. It'd give an array similar to $_GET. request_query_string_get($name): gets the value of $name in the parsed query string. Calls request_query_string_parse() if it hasn't been called before. Basically, stop using the mess that superglobals currently are ($_REQUEST or $_SERVER), and start providing a sane, *very basic* API. The functionality remain the same, yet the API is actually sane. It allows userland to use this basic API and can easily build up on it. Maybe this is actually a non-issue and I'm thinking too much... just my $0.02. Regards, On Tue, Oct 14, 2014 at 6:18 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 10/14/2014 09:15 AM, Mike Dugan wrote: > > On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com > > <mailto:ras...@lerdorf.com>) wrote: > >> On 10/14/2014 06:29 AM, Andrea Faulds wrote: > >> > > >> > On 14 Oct 2014, at 14:27, Kristopher <kristopherwil...@gmail.com> > wrote: > >> > > >> >> $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. > >> > > >> > Ew, non-superglobals. > >> > > >> > But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps > $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally > makes sense, but isn’t too long: > >> > > >> > * $_QUERY - query string parameters > >> > * $_BODY - request body parameters > >> > * $_REQUEST - query string and request body parameters > >> > > >> > Makes more sense than $_GET and $_POST. > >> > > >> > Any objections? > >> > >> It makes no sense to me to make $_BODY an alias for $_POST. $_POST > >> implies the default body encoding that a broswer performs on a POST > >> request. Making an alias called $_BODY that doesn't contain the body of > >> a request unless it is "POST"-encoded would be super confusing. > >> > >> I think the pedantry level around this is rather high. Nobody is > >> actually confused about $_GET and $_POST and how and when to use them. > >> Adding vague aliases adds confusion to something that had no confusion > >> before. > >> > >> -Rasmus > >> > >> > > For clarity, $_BODY was revised to $_FORM. > > > > I think there was some misunderstanding of the usage of $_GET earlier in > > this thread, although I may have misunderstood someone’s wording. > > Regardless, if I go out and sample 100 PHP folks, I’m fairly confident > > someone would make the association that either $_GET or $_POST is bound > > strictly to the HTTP verb of the same name. Adding aliases gives these > > vars a more semantic name while not causing a massive BC breakage. > > I think 20+ years of history has proven this to be a non-issue. Of all > the things that people get confused by in PHP, $_GET/$_POST are right > near the bottom of the list. > > -Rasmus > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Florian Margaine
