Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77989
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <E8F7D721-767C-4E6E-B0BB-F0DEFEB308B2@ajf.me>
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>
Date: Tue, 14 Oct 2014 14:30:31 +0100
Message-ID: <CAGAGxbYBO_E-tf7SipgRDgy-kQZiwF96QGSAwGcJpc2zZ=GGNw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Andrey Andreev <narf@devilix.net>, Kris Craig <kris.craig@gmail.com>, 
	PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: cw@daverandom.com (Chris Wright)

On 14 October 2014 14:25, Andrea Faulds <ajf@ajf.me> wrote:
>
> On 14 Oct 2014, at 14:23, Andrey Andreev <narf@devilix.net> wrote:
>
>> That being said, from a purely semantic prospective, both $_GET and
>> $_POST should be tossed - yes. In reality, you can't do that because
>> virtually all PHP applications use them. But this is no reason to add
>> even more global vars with such misleading ... meanings.
>
> Let=E2=80=99s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases=
 of $_GET and $_POST then. Because they=E2=80=99re aliases (by-reference su=
perglobals), there=E2=80=99s no additional memory consumption, but we final=
ly have saner names.

$_BODY and $_QUERY would be better, IMHO. The brevity would be
consistent both historically and with other existing superglobal
names, and at least with $_QUERY_STRING the data is not a string.

I suggested this a while ago, people didn't like the idea, and I'm not
sure I do any more, either. We'd do much better focusing on creating a
standard native request *object* which provides clean access to this
data, and other things that are clumsy at the moment, such as request
headers.