Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89961
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <CAF+90c_T7KZPy3h-yiak+09NZMF7UR9h8fjc-E-Vf7btFfBnLw@mail.gmail.com>
References: <CAEYWF=7Px5LWGdGqHdmVwt_tWd-XAUhZzUFoOa_rDmtpi88BAA@mail.gmail.com>
 <CAF+90c_T7KZPy3h-yiak+09NZMF7UR9h8fjc-E-Vf7btFfBnLw@mail.gmail.com>
Date: Fri, 1 Jan 2016 22:09:42 -0500
Message-ID: <CAEYWF=6A4mpS5Y1KU+jZzU9hyS=ViysS_O6_5p6vMb8zmQHgvQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3a840ad90b670528513970
Subject: Re: [PHP-DEV] [RFC] On-Demand Name Mangling
From: bishop@php.net (Bishop Bettini)

--047d7b3a840ad90b670528513970
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 1, 2016 at 5:11 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Fri, Jan 1, 2016 at 10:47 PM, Bishop Bettini <bishop@php.net> wrote:
>
>> Hello Internals,
>>
>> Ringing in the new year with a proposal to retool name mangling:
>>
>> Mangling has the undesirable consequence that many external variables may
>> map to one PHP variable. This leads to user confusion and user-land
>> workarounds, not to mention bug reports. Since register_globals has been
>> removed, we can replace automatic name mangling with on-demand mangling
>> via
>> extract(). This allows a one-to-one between external and PHP super-global
>> variables, while fixing a few bug reports on extract as well.
>>
>> RFC: https://wiki.php.net/rfc/on_demand_name_mangling
>>
>> Thanks in advance for your feedback!
>> bishop
>>
>
> I like the idea of getting rid of name mangling, but don't like the
> particular approach you propose here. In particular anything that will
> result in an arbitrary number of deprecation notices *controlled by user
> input* is a no go for me.
>

Agreed.  The message intends to provide some warning to application
developers when there is known use of name mangling. As such, a single
warning when the mangler runs is sufficient to meet this intent.


I think this is one of the rare cases where I would favor the introduction
> of a new ini setting. E.g. mangle_names=0 disables name mangling, while
> mangle_names=1 throws a deprecation warning on startup and enables name
> mangling. mangle_names=0 should be the default. That is essentially disable
> name mangling, but leave an escape hatch for those people who rely on it
> (for whatever reason).
>

An INI setting to disable mangling must be engine-wide. In a hosted
environment where many unrelated sites share the same engine configuration,
it's possible that one site might require mangling while another site
requires no-mangling. These two sites could not co-exist with an engine
setting.

But, even without a setting, there's an escape hatch: userland can polyfill
the mangling behavior using extract.  The updated RFC demonstrates an
algorithm.



> Furthermore I don't like the suggestion that extract() should start
> mangling names by default. Currently "invalid" variable names will be
> ignored by extract(). We can introduce a EXTR_MANGLE_INVALID option for
> those who want it. Additionally we can also provide an EXTR_ALLOW_INVALID
> option, which simply extracts "invalid" names normally. (Imho that should
> be the default behavior. "Invalid" in this context is a misnomer, these
> variable names are perfectly fine and easily accessible.)
>

Agreed, that would unnecessarily introduce a BC break on extract.  A new
option makes the most sense.

I've updated the RFC in light of all your comments/suggestions.  Thanks for
them!

--047d7b3a840ad90b670528513970--