Erratum: all the request_* functions except request_get() take the request object/array as 1st argument.
Le 14 oct. 2014 18:21, "Florian Margaine" <flor...@margaine.com> a écrit : > > 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
