Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98933
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
To: Andrey Andreev <narf@devilix.net>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAPhkiZzzgmWcqsVPKghv89XU3+Ab06wcXbqeBc1MSh401_+etw@mail.gmail.com>
Message-ID: <a8aa62c3-ac5f-5c84-4662-e86ccf9abded@gmx.de>
Date: Tue, 2 May 2017 16:07:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: <CAPhkiZzzgmWcqsVPKghv89XU3+Ab06wcXbqeBc1MSh401_+etw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [Discussion] Dots and spaces in GPC variable names
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 02.05.2017 at 12:56, Andrey Andreev wrote:

> With parse_str() usage without a second parameter being deprecated, I
> was looking to possibly drop the behavior where it replaces spaces and
> dots with underscores in the result array, and ... As it often turns
> out - it's not that simple, because it re-uses the code that handles
> GPC vars.
> 
> I didn't even know this mangling happened with GPC vars. I can only
> assume that's legacy from the the register_global days, as I certainly
> don't see a reason for it now. Am I missing something?
> 
> And more importantly, can we change that? It's a significant BC break,
> yes, but the current behavior is horribly broken IMO.

This issue has been already brought to the list quite a while ago[1].
IMHO, the big problem is the subtle BC break.

[1] <http://marc.info/?l=php-internals&m=144416398306733&w=2>

-- 
Christoph M. Becker