Closed steelbrain closed 8 years ago
IMO, this shouldn't change until PHP itself changes it.
@derickr Any good reason to be compatible with PHP here? I mean, I am talking about an ini setting which toggles it.
I dislike this: it's a subtle behavior change that can't be easily be picked up by an application unit test.
@fredemmott while I agree that one can easily understand with an application unit test what php is doing. But it also limits one's ability to distinguish between inputs. I mean a.b
and a_b
are treated as same. One can't have them both at the same.
Adding an ini settings encourages the writing of non-portable applications. If you have written it for HHVM with the ini setting set to On, then you can never run it on plain PHP again. ini settings in general make code less portable, as in many cases a developer might not have access to set it, and hence, developers of apps that need to deploy now need to account for the setting being on, or off. — and then only for HHVM.
@derickr I am not sure what you mean by portable here but I am pretty sure that PHP runtime can't run my hacklang application. I am just asking for a way to disable the madness php has introduced in the lang.
Having your application depend on ini settings is not good practice.
An alternative less likely to lead to problems would be to add a new API and discourage usage of the superglobals in Hack applications.
This feature request is not actively being worked on. We would happily consider a pull request implementing it. If you plan to work on this issue let us know in the comments and we will re-open the issue and assign it to you. If you feel strongly that this issue deserves more attention, please comment here with your use-case and we will try to prioritize as appropriate.
It is like that because
register_globals
wouldn't work with dots, but now that we all know the benefits of it ( :laughing: ) how about we have a ini setting that disables it? /cc @sgolemon @SiebelsTim @danslo