> > > > I did not intend for all unqualified calls to become global, unless > > the new directive is present. > > 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. 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. 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. > > 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. > 2. If the vote is accepted, it would void my suggestion, because it > is not compatible with the conditions laid out in your proposal. I don't see them as being incompatible at all, they would actually work together. An automatic performance improvement for everyone without any BC breaks or code changes, plus a new option that gives advanced developers a new tool to write cleaner class code, and enable advanced unit testing tools to work. > > A vote with multiple options to pick an approach (opt-in through some > directive, hard BC break, flipping lookup order, nothing at all) > might be more appropriate. A vote has not been called, and an RFC is supposed to be amended in response to comments and discussion. 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. Please, let us discuss.
