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.
without building a whole HTTP framework into the core.
I'm devoutly anti-framework and I don't think anyone is actually advocating
this. If you read closely I'm arguing against adding more superglobals.
I'm also against changing the names of the existing arrays as any
improvement is far outweighed by the massive BC implications of such a
change. I personally don't care whether or not a better request model is
implemented in core -- I've already unlearned the bad-habits ingrained at
the language-level.
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]