On Mon, Aug 5, 2024 at 3:33 PM Nick Lockheart <li...@ageofdream.com> wrote: > > This is a different problem that could be solved by a sandbox API.
Not sure which case we were talking about then. ClockMock is what I've been referencing all along. > > 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. Right. But apart from mocking, what are these cases? If performance were no longer an issue, "using global functions" just makes the language harder to use, removing the local fallback. "using local functions" may be useful in namespaced code making many calls to functions within the same namespace. In that case, it would probably be more useful to switch the lookup order back instead. If you want to pay zero performance penalty, you can prefix global calls with \. You'd need to do that with "using local functions" anyway. As for mocking: If the code needs to change either way, why not make it testable in the first place, e.g. through dependency injection for time()? At least this only requires changing the calls that are mocked, instead of all the calls that aren't. The main benefit of the approach from ClockMock is that your code (probably) doesn't need to change. I do think that the entire approach is hacky, and probably worth solving on a language-level, at least if possible without adding limitations to the engine. A good first start would be to know what functions are commonly mocked with this approach. Ilija
