Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89963
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <568742A6.8070400@gmail.com>
References: <CAEYWF=7Px5LWGdGqHdmVwt_tWd-XAUhZzUFoOa_rDmtpi88BAA@mail.gmail.com>
 <568742A6.8070400@gmail.com>
Date: Fri, 1 Jan 2016 22:51:03 -0500
Message-ID: <CAEYWF=4U8bLmLbo=dZ6ZsVD0nX9U32bjhL9OLhtPfB6vGMpkhg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3a840ac240ed052851cdfc
Subject: Re: [PHP-DEV] [RFC] On-Demand Name Mangling
From: bishop@php.net (Bishop Bettini)

--047d7b3a840ac240ed052851cdfc
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 1, 2016 at 10:23 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > Ringing in the new year with a proposal to retool name mangling:
>
> While the variable name changing probably outlived its usefulness with
> the demise of register_globals, changing it would produce serious BC
> issues with which we should be very careful.


Agreed!


> Emitting E_DEPRECATED based
> on user data certainly does not sound like a good idea.
>

Agreed. I updated the RFC to throw a notice only once (per startup) and
only if the mangler fires up.  This is similar in spirit to the
datetime.timezone setting.


> I like Nikita's proposal on both counts - making it an config switch (as
> much as I hate those) and have extract() flag for this (I would make the
> current behavior default to minimize BC disruption).
>

In my 1.1 update to the RFC, I contend that a config switch will cause
problems in some cases.  Specifically, the logic goes like this.  The
config must be PHP_INI_SYSTEM. An engine wide config affects all sites in a
shared hosting environment. If one of these sites requires mangling, while
another site requires no mangling, we have an operational conflict. The
only way to solve that is by giving each site its own engine, which isn't
tenable in a shared environment.

My RFC update further contends that a userland polyfill solves the BC issue
without a config switch. Here's how: The engine is updated to not mangle.
The polyfill provides a function that uses extract() to mangle the
superglobals.  Userland can maintain BC by composing in (or writing their
own) polyfill. This approach improves the engine while giving existing
sites an escape hatch.


> I don't see why it says in the RFC it should be PHP_INI_ALL - I think it
> should be PHP_INI_SYSTEM or PHP_INI_PERDIR, as changing it at runtime
> won't do anything useful - the values should already be loaded.
>

That was a typo. Fixed.

Thanks!

--047d7b3a840ac240ed052851cdfc--