On Mon, Aug 5, 2024 at 2:27 PM Nick Lockheart <li...@ageofdream.com> wrote: > > > > I'm not sure your proposal solves the mocking problem. If the engine > > is to interpret all non-fq calls as global or local, how would a > > library include your file while switching this configuration, when it > > is implemented as some directive in the file? > > I'm not sure I understand this question.
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. > > Also, how would only singular functions be mocked when there is no > > fallback to the global scope for the rest of the functions used > > within the file? That would necessitate mocking all functions, even > > the unmodified ones. > > If a developer needed to override built-in functions (in a specific > file) with local ones, and still use some built-in functions, they > would then need to use the fully-qualified `\function();` to call the > built-in. Well, ok. But then we're back to prefixing global calls, which defeats the purpose of the proposal. I think it's much preferable to look for a different, more robust mocking solution that also works for unnamespaced code and fully qualified calls. Ilija
