On Fri, Aug 23, 2024, at 21:41, Rowan Tommins [IMSoP] wrote:
>
>
> On 23 August 2024 18:32:41 BST, Ilija Tovilo <[email protected]> wrote:
> >IMO, 1. is too drastic. As people have mentioned, there are tools to
> >automate disambiguation. But unless we gain some other benefit from
> >dropping the lookup entirely, why do it?
>
> I can think of a few disadvantages of "global first":
>
> - Fewer code bases will be affected, but working out which ones is harder. The easiest
> migration will probably be to make sure all calls to namespaced functions are fully qualified, as
> though it was "global only".
> - Even after the initial migration, users will have to watch out for new conflicting global
> functions. Again, this can be avoided by just pretending it's "global only".
> - The engine won't be able to optimise calls where the name exists locally but not
> globally, because a userland global function could be defined at any time.
> - Unlike with the current way around, there's unlikely to be a use case for shadowing a
> namespaced name with a global one; it will just be a gotcha that trips people up occasionally.
>
> None of these seem like showstoppers to me, but since we can so easily go one step further to
> "global only", and avoid them, why wouldn't we?
>
> Your answer to that seems to be that you think "global only" is a bigger BC break,
> but I wonder how much difference it really makes. As in, how many codebases are using unqualified
> calls to reference a namespaced function, but *not* shadowing a global name?
I can think of more than one one-off script where I have written something like this:
namespace blah;
function read_and_process_file(): array {
}
function do_something(array $file): void { }
$file = read_and_process_file();
var_dump($file);
// die(); // debug
do_something($file);
If it were global only, then how would I call those files? namespace\read_and_process_file()?
That seems worse ergonomics and not better, for very little gain.
>
> Regards,
> Rowan Tommins
> [IMSoP]
>
— Rob