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
