On Mon, Aug 5, 2024 at 10:22 AM Nick Lockheart <li...@ageofdream.com> wrote: > > > Sorry, my language was not precise enough. Your proposal suggests > > making unqualified calls global when the directive is present, > > whereas my proposal suggests keeping local scope as a fallback, hence > > the two not being compatible. > > Keeping local scope as a fallback would still require an NS lookup > opcode.
In the general sense: Yes, we would need to keep the NS lookup opcode. However, functions that are known to exist in global scope would not compile to it. The same goes for your solution, as code that doesn't opt-into disambiguated lookups will still require the ZEND_INIT_NS_FCALL_BY_NAME opcode. > My proposal is that there still be an NS lookup as the default > behavior, but allow an optional override. > > That is, users would have three options: > > (1) resolve all unqualified function names to global (no NS lookup) > (2) resolve all unqualified function names to local (no NS lookup) > (3) Use the default behavior, which at present, is local first, then > global, with a namespace lookup. (no change to user code, keeps BC) > > Your proposal reverses the order of the default NS lookup from local > first to global first. > > That's not mutually exclusive. Sure. But it's questionable whether the motivation of introducing one when the other already exists is still there. > If my proposal *and* yours were *both* accepted, users would have these > options: > > (1) resolve all unqualified function names to global (no NS lookup) > (2) resolve all unqualified function names to local (no NS lookup) > (3) Use the default behavior, which would now be global first, then > local, with a namespace lookup. (no change to user code, keeps BC > working, but changes the default automatic lookup order) > > I believe that my propsal also helps yours be more viable, too. Because > if your proposal was accepted alone, and the NS lookup order changed, > then it would no longer be possible to do unit testing with stubs that > replace built-in functions, UNLESS there was also an option for > developers to instruct the compiler to use local functions over global > ones. 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? 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. > > What I'm saying is that: > > > > 1. If the vote fails, it might have been because some people don't > > want opt-in behavior. Niels just voiced this opinion. > > Every token added to a PHP file is opt-in behavior that changes how the > parser works. I don't understand what you mean. What Niels was suggesting is that adding more context dependency is undesired. I.e. language semantics should not be dependent on configuration. > I think something needs to be at least as formal as an RFC or people > won't take it seriously enough to contribute feedback. > > I'm trying to start a discussion on this and get some momentum so that > we can hopefully implement something in a near future version. Fair enough. But it should be made clearer what is being voted on. >From reading the RFC, it is not clear that there even are alternative options, which ones have been proposed before, what points have been raised in the discussion, etc. Ilija
