Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69510
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
Message-ID: <52531955.1010804@gmail.com>
Date: Mon, 07 Oct 2013 21:28:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CAH8MpnkgubiJ3VUkRN9r1tUzzQ2m-Cr13-TViu2Z5atMy49NiA@mail.gmail.com>
In-Reply-To: <CAH8MpnkgubiJ3VUkRN9r1tUzzQ2m-Cr13-TViu2Z5atMy49NiA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------070605080801020405010403"
Subject: Re: HTTP supergloblas and request body/query (was: Parsing PUT data)
From: rowan.collins@gmail.com (Rowan Collins)

--------------070605080801020405010403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 07/10/2013 18:19, Daniel Lowrey wrote:
> >> You can't efficiently model an HTTP request with associative 
> arrays. Period.
>
> > The fact is that for 99% of use cases, yes you can, and developers
> > happily do so.
>
> Leaky abstraction is leaky. If this is truly an efficient model of the 
> HTTP request then why do we fragment it out into $_SERVER and 
> $_COOKIES and $_FILES and $_POST and $_GET and php://input? I don't 
> know what your definition of "efficiently model" is, but it must be 
> different from mine. Array Oriented Programming !== design.

Ah, OK, I was only really talking about $_POST and $_GET, since they 
were the topic of this thread. I'm not quite sure why breaking different 
aspects of the HTTP request into different interfaces is fundamentally a 
problem, but I agree that you can't model /all/ aspects of an HTTP 
request as associative arrays.

To go through the relevant superglobals in turn:

$_GET: The param=value&... format for query strings is so universal, 
whether or not generated by a form, that it can largely be taken for 
granted. Within that format, the only thing that can't be handled as a 
hash is a repeated key; PHP takes the approach that foo[]=bar always 
creates an array, and foo=bar never does, with later values "winning". 
This covers 99% of what people need to do with query strings.

The mutability and globalness aren't great, but any method 
->getQueryStringParam('foo') would be indistinguishable from 
->getQueryStringHash()['foo']

$_POST: Deals with the two generally accepted form encodings for POST 
requests, in a way that matches $_GET, but while allowing programmers to 
distinguish the two rather than clobbering thm into one array.

$_COOKIE: Again, the structure of the Cookie: header in PHP is 
fundamentally a set of name=value pairs, making a hash a perfectly 
reasonable structure. The asymmetry with set_cookie() is unfortunate, 
although some asymmetry is inevitable given the underlying headers. At 
least it's better than the abomination that is document.cookie :P

$_REQUEST: This is an unnecessary bit of redundancy, although it reminds 
me that if you do want to merge query string and posted data, having 
them as hashes is very handy.

$_FILES: A bit awkward. I can guess the argument for splitting it from 
$_POST, but it's crying out for a more OO representation of the 
individual entries. They're still name-value pairs though.

$_SERVER: This is the only one that really doesn't work at all. I was 
going to mention it earlier, but didn't want to drift off-topic in my 
earlier messages. It's an awful jumble of HTTP headers, PHP-specific 
data, and arbitrary environment variables which happen to have come 
through from the SAPI. It contains the requested URL in various parts 
with inconsistent names, and I refuse to go near it without a sane 
wrapper class.

HTTP headers are fundamentally key-value pairs, although they can 
repeat, so more like key -> array of values. Environment variables are 
key-value too. The rest of it, along with 
file_get_contents('php://input'), is odds and ends that need a separate 
abstraction.

Well, that's the way I see it anyway. The superglobals themselves aren't 
great, but outside of APIs (which will generally involve a bit of 
framework-y-ness anyway) the associative array interface is what most 
people will end up wanting anyway.

Regards,
-- 
Rowan Collins
[IMSoP]

--------------070605080801020405010403--