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
