> 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.
Really, all we are doing here is telling the parser to pretend that any
function call without a namespace was coded with a `\` in front of it.
In other words:
"Parser, if you see `array_key_exists()`, pretend you saw
`\array_key_exists()` and use the dedicated opcode".
The engine wouldn't change at all. The only thing changing is the
opcode being generated. And the opcodes aren't changing either.
The parser would do the same thing as having a backslash does now. You
just wouldn't need to explicitly put the backslash there. It assumes
the backslash.
Or, to put it another way, we are simply specifying what the default
namespace is for unqualified calls.
> 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.
Consider this very brief example:
// MockFileFunctions.php
namespace test;
function fopen{
echo 'pretending to write files!';
}
// TestClass.php
namespace test using local functions;
class TestClass{
function TestMethod(){
// array_key_exists uses built-in due to leading \
if(\array_key_exists(...)){
// fopen uses \test\fopen because of "using local functions"
fopen('file.txt');
}
}
}
In the example above, we have specified "using local functions", which
prevents namespace lookup of functions, and defaults to local if the
function name is unqualified.
The backslash before \array_key_exists() triggers the global version,
even though this file specifies "using local functions". That's because
"using local functions" only applies to *unqualified* function calls
and the backslash qualifies it as global.
"Using local functions" would only ever be used in very special use
cases like unit testing.
The most common use case would be for the companion declaration: "using
*global* functions".
When "using global functions" is declared, the backslash is omitted
from all function calls where the global function is desired, and the
parser pretends a backslash is there (if there isn't a namespace
specified for that function call).
This boosts performance by skipping the ns lookup and by using
dedicated opcodes, while also keeping code clean in the vast majority
of use cases where only global functions are ever used by namespaced
classes.
