Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78032
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain margaine.com from 209.85.213.178 cause and error)
MIME-Version: 1.0
In-Reply-To: <CABRjmp8kJvStPybGXSs5o8HgzRRy45G5XQdCmcNm+hKZZiT=Sw@mail.gmail.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>
	<CABRjmp8kJvStPybGXSs5o8HgzRRy45G5XQdCmcNm+hKZZiT=Sw@mail.gmail.com>
Date: Tue, 14 Oct 2014 18:28:06 +0200
Message-ID: <CABRjmp-79+y-6T95j__wpVDFc0a=wQQ9AJFbZQwo8COrcQbNwA@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Kristopher <kristopherwilson@gmail.com>, Mike Dugan <mike@mjdugan.com>, 
	Andrey Andreev <narf@devilix.net>, PHP internals list <internals@lists.php.net>, Andrea Faulds <ajf@ajf.me>, 
	Kris Craig <kris.craig@gmail.com>
Content-Type: multipart/alternative; boundary=20cf302446ad10a2360505648065
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: florian@margaine.com (Florian Margaine)

--20cf302446ad10a2360505648065
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Erratum: all the request_* functions except request_get() take the request
object/array as 1st argument.

Le 14 oct. 2014 18:21, "Florian Margaine" <florian@margaine.com> a =C3=A9cr=
it :
>
> 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 finally
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
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 confusio=
n
>> >> 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=E2=80=99s wordi=
ng.
>> > Regardless, if I go out and sample 100 PHP folks, I=E2=80=99m fairly c=
onfident
>> > someone would make the association that either $_GET or $_POST is boun=
d
>> > 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

--20cf302446ad10a2360505648065--