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]
