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

Reply via email to