On Fri, Jan 1, 2016 at 5:11 PM, Nikita Popov <nikita....@gmail.com> wrote:
> On Fri, Jan 1, 2016 at 10:47 PM, Bishop Bettini <bis...@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!
