On Fri, Aug 23, 2024, at 14:16, Rob Landers wrote: > On Fri, Aug 23, 2024, at 11:27, Nick Lockheart wrote: >> On Fri, 2024-08-23 at 09:16 +0100, Rowan Tommins [IMSoP] wrote: >> > >> > >> > On 23 August 2024 01:42:38 BST, Nick Lockheart <li...@ageofdream.com> >> > wrote: >> > > >> > > > >> > > > BUT, if people already complain about "\" being ugly, having to >> > > > write >> > > > "namespace\" is going to make them REALLY grumpy... >> > > > So maybe at the same time (or, probably, in advance) we need to >> > > > come >> > > > up with a nicer syntax for explicitly referencing the current >> > > > namespace. >> > > >> > > namespace foo using global functions; >> > > >> > > - or - >> > > >> > > namespace foo using local functions; >> > > >> > > >> > > Tell PHP what you want at the per-file level. >> > >> > >> > This doesn't seem mutually exclusive to me. If you have a file where >> > you've opted for "using global functions", you might want a way to >> > reference a function in the current namespace. >> >> Correct, so if you use the example: >> >> namespace foo using global functions; >> >> you can write: >> >> array_key_exists(); >> >> and it will be resolved as global without a namespace lookup and will >> use the dedicated opcode. >> >> But if you need to use a local function you can do: >> >> \foo\sort(); >> >> >> The proposed global/local declaration as part of the namespace >> declaration just turns off namespace lookups and sets the default >> resolution for **unqualified** names. >> >> Fully qualified names are not affected. >> >> >> > It also doesn't address my other point, that having global as the >> > default mode (even if we provide an option for local) is much less >> > disruptive to existing code. >> >> >> They are compatible, but related decisions. >> >> I think it would be easier for people to accept a new PHP version where >> unqualified names were always global, if we also had an option to make >> local/namespaced the default resolution for *unqualified* names, on a >> per-file basis, for those who need that. >> >> >> Thus, there are multiple decision points: >> >> 1. Should we do namespace lookups on unqualified function calls at all? >> >> 2. If yes to 1, should we lookup in global first or local first? >> >> 3. Regardless of 1 or 2, should we let developers explicitly specify a >> behavior for unqualified calls in the namespace declaration? >> >> 4. If yes to 1, should the behavior of namespace lookups change for >> user-defined functions vs PHP built-in function names? >> >> >> These aren't mutually exclusive, but they all work together to create a >> complete behavior. >> >> There are several ways that the above options could be combined: >> >> >> >> ### OPTION ONE ### >> >> Using a regular namespace declaration still does an NS lookup, in the >> same order, just like it normally works now. >> >> That means that code that uses: >> >> namespace foo; >> >> will behave exactly the same as today, with no BC breaks. >> >> Developers using the new PHP version could opt-in to explicit namespace >> behavior with: >> >> namespace foo using global functions; >> >> or >> >> namespace foo using local functions; >> >> In both cases, *fully-qualified* names still work the same. >> >> Only *unqualified* names are affected by this directive, and they use >> local only or global only, depending on the declaration. >> >> >> >> ### OPTION TWO ### >> >> Namespace lookup is removed from a future version of PHP. >> >> Code that uses the current namespace declaration: >> >> namespace foo; >> >> will assume that all unqualified function calls are global scope. >> >> To use a function in the local namespace, it can be fully qualified >> with: >> >> \foo\MyFunction(); >> >> >> But, developers could also write: >> >> namespace foo using local functions; >> >> And all unqualified function names would be resolved to local at >> compile time. Global functions could still be accessed with a `\` if >> this directive was used: >> >> \array_key_exists(); >> >> >> >> ### OPTION THREE ### >> >> Namespace lookup is removed from a future version of PHP. >> >> Code that uses the current namespace declaration: >> >> namespace foo; >> >> ...will assume that an *unqualified* function name is a global function >> *IF* it is a PHP built-in function. >> >> Otherwise, *unqualified* function names that are *not* PHP built-in >> functions will be presumed to be local to the namespace. >> >> With Option Three, developers can still fully-qualify their functions: >> >> \foo\array_key_exists(); >> >> ...to override a built-in name with a user function in the current >> namespace. >> >> Likewise, a fully-qualified: >> >> \MyFunction(); >> >> called from inside a namespace will still call the global function. >> >> Only unqualified names are affected. >> >> As an additional optional feature of Option Three, developers can >> change this behavior with: >> >> namespace foo using global functions; >> >> or >> >> namespace foo using local functions; >> >> >> Only *unqualified* names are affected by this directive, and they use >> local only or global only, depending on the namespace declaration. >> >> In both cases, *fully-qualified* names still work the same. >> >> >> >> Of course, there are many other possibilities that can be mixed-and- >> matched. >> > > I personally would find option 3 to be the best of both worlds, and you don't > even need the `namespace ... using ... functions` stuff. > > — Rob
Totally sent that before finishing... My only two concerns are: 1. Calling functions in the current namespace. I don't want that syntax to change. 2. Changing the order might make function autoloading impossible; forever. If these concerns can be ameliorated, then I don't really care much about the specifics. — Rob
