> > Consider this example: > > <?php > namespace Foo; > echo time(); > > With my proposal, this would now always call the global time() > function. You were suggesting that "using local functions" would help > mitigate this, but I don't think it does. > > * The user can't add "using local functions" to this file, because in > a production environment where ClockMock isn't used, there is no > local > time() function. With "using local functions" having no fallback, the > global function would not be called, and hence the code would error. > Your proposal would only help if the semantics were "use local > function if available, or global function otherwise", which is what > we > have currently. > * Symfony can't enable the "using local functions" option either when > including your file, because it would require modifying the source > code. That leaves eval(), which would really already solve this > problem if you replace calls to time() with something else.
This is a different problem that could be solved by a sandbox API. > Well, ok. But then we're back to prefixing global calls, which > defeats the purpose of the proposal. Global functions would only need a prefix `\` in the *very rare* cases where local functions are set as the default. For most people, the \ would be omitted, as globals would be set as default for unqualified function names.
