Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78031
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain margaine.com from 209.85.213.181 cause and error)
MIME-Version: 1.0
In-Reply-To: <543D4CE1.5000109@lerdorf.com>
References: <CAKOpQSwS=Xck41sQQyEYGG8L3VHq+fRWjy0dDorbwZaVWMLCow@mail.gmail.com>
 <776669CE-9E8C-4069-9834-C7275CCA0EF4@ajf.me> <CAKOpQSwRtSU1LNmftyY1b09SONBCfwS-qiMK4gct6uFiW3CSjw@mail.gmail.com>
 <CAPhkiZwb13FmX+sQLx0Ki52KuwJ4HWTj-84UqcZq3GYPFL8Tnw@mail.gmail.com>
 <E8F7D721-767C-4E6E-B0BB-F0DEFEB308B2@ajf.me> <CAF9U7z_0cgwWFEoShU9rJhoOZttztcZk_NAqoXnSuAro-w3kew@mail.gmail.com>
 <8CB055D4-F164-4DF3-B019-684BAE7E016E@ajf.me> <543D47C1.9050009@lerdorf.com>
 <etPan.543d4c0e.216231b.12d@Mikes-iMac.local> <543D4CE1.5000109@lerdorf.com>
Date: Tue, 14 Oct 2014 18:21:49 +0200
Message-ID: <CABRjmp8kJvStPybGXSs5o8HgzRRy45G5XQdCmcNm+hKZZiT=Sw@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Mike Dugan <mike@mjdugan.com>, Andrea Faulds <ajf@ajf.me>, 
	Kristopher <kristopherwilson@gmail.com>, PHP internals list <internals@lists.php.net>, 
	Andrey Andreev <narf@devilix.net>, Kris Craig <kris.craig@gmail.com>
Content-Type: multipart/alternative; boundary=20cf302446adcb6d550505646a33
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: florian@margaine.com (Florian Margaine)

--20cf302446adcb6d550505646a33
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <rasmus@lerdorf.com> wrote:

> On 10/14/2014 09:15 AM, Mike Dugan wrote:
> > On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (rasmus@lerdorf.com
> > <mailto:rasmus@lerdorf.com>) wrote:
> >> On 10/14/2014 06:29 AM, Andrea Faulds wrote:
> >> >
> >> > On 14 Oct 2014, at 14:27, Kristopher <kristopherwilson@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 finall=
y
> makes sense, but isn=E2=80=99t 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 o=
f
> >> 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 i=
n
> > this thread, although I may have misunderstood someone=E2=80=99s wordin=
g.
> > Regardless, if I go out and sample 100 PHP folks, I=E2=80=99m fairly co=
nfident
> > 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
>
>


--=20
Florian Margaine

--20cf302446adcb6d550505646a33--