Re: [RFC] On-Demand Name Mangling

On Mon, Jan 4, 2016 at 5:16 PM, Bishop Bettini <bishop@php.net> wrote: > On Sat, Jan 2, 2016 at 11:45 AM, Rowan Collins <rowan.collins@gmail.com> > wrote: > >> On 02/01/2016 03:09, Bishop Bettini wrote: >> >>> But, even without a setting, there's an escape hatch: userland can >>> polyfill >>> the mangling behavior using extract. The updated RFC demonstrates an >>> algorithm. >>> >> >> I'm not that comfortable with requiring / encouraging the use of >> extract() - a rather awkward function which clobbers your local variable >> space in unpredictable ways - to write the polyfill. The fact that the >> clobbering is necessary / useful for extract() is wholly unrelated to the >> need for BC in super-global arrays. >> >> It would be more useful to expose a method or regex constant to userland >> so that the mangling can actually be done in place on appropriate arrays: >> > > I've updated the on-demand name mangling RFC > <https://wiki.php.net/rfc/on_demand_name_mangling> in > light of all > feedback so far. The crux being: > > - If an app requires name mangling: > - As of 7.1, the app will get one E_NOTICE per startup warning of > the impending removal of name mangling > - As of 8.0, the app will need to include a polyfill package and > add one line of code to its bootstrap. (Safe to include the polyfill prior > to the release of 8.0.) > - If an app does not need name mangling, there's no effect, no > notices, nothing needed > > Thanks! > I still don't like this part: > As written, one can't: the engine emits the error as soon as it mangles a variable, at most one time per startup. While that's annoying, it's also informative: someone's hitting your application in a way that may not expect. Even if it's only a single deprecation warning instead of multiple, it's still a deprecation warning that I, as the application author, have absolutely no control over. For me, a deprecation warning indicates that there is some code I must change to make that warning *go away*. Sure, it's informative. But it's enough to be informative about this *once*, rather than every time a user makes an odd-ish request. If we don't want to introduce an ini setting (against which there are good reasons, as you have outlined) I'd just mark this as deprecated with a nice red box in the documentation and upgrading guide, and commit to dropping it in 8.0, but not throw actual deprecation notices. Nikita