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 <[email protected]>
>> > 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