Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98943
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <a8aa62c3-ac5f-5c84-4662-e86ccf9abded@gmx.de>
References: <CAPhkiZzzgmWcqsVPKghv89XU3+Ab06wcXbqeBc1MSh401_+etw@mail.gmail.com>
 <a8aa62c3-ac5f-5c84-4662-e86ccf9abded@gmx.de>
Date: Tue, 2 May 2017 22:48:56 +0300
Message-ID: <CAPhkiZz=0ZtL0yY4MedGip0-5eyOrBYBPqfyhaVEtR_JyuoX4w@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Discussion] Dots and spaces in GPC variable names
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, May 2, 2017 at 5:07 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> 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>
>

Thanks for linking that. It's encouraging as I'd expect a previous
discussion to have gathered mostly negative opinions due to the BC
break.

That old thread is from just the time when 7.0 was supposed to be
released, so it was certainly an opportunity missed by a few months.
I'm not surprised by the suggestion for targeting 8.0, but perhaps we
could think of a way to conditionally disable the mangling in 7.x and
then remove it entirely in 8?
I hate to say INI directives, but that's surely one way for a smoother
transition.

Cheers,
Andrey.