On 14 October 2014 14:46, Kris Craig <kris.cr...@gmail.com> wrote:
> On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan <m...@mjdugan.com> wrote:
>
>>
>> On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote:
>>
>>
>> On 14 Oct 2014, at 14:27, Kristopher <kristopherwil...@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’t 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?
>>
>> --
>> Andrea Faulds
>> http://ajf.me/
>>
>>
>> +1 for this. This would hopefully also eliminate the confusion for new
>> developers (or not-so-new developers) who don’t quite understand that $_GET
>> and $_POST don’t strictly relate to their HTTP verbs of the same name.
>>
>> --
>>
>> Mike Dugan
>>
>> m...@mjdugan.com
>>
>
> That could work, though the BC breakage will be extreme.  I'm not sure if
> that's worth it even in a major version increment.  On the other hand,
> making $_PUT and $_DELETE available wouldn't break anything and wouldn't
> require re-training for devs.

...but is also the wrong solution. It's not scalable, and the only
sensible way to implement them would be as aliases of $_POST, because
they would contain the same data. How does this fundamentally differ
from $_BODY (or whatever)?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to