> On Aug 22, 2024, at 5:32 PM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk>
> wrote:
> I was thinking about this earlier, and how the migration is pretty much the
> same (and equally automatable) in either direction:
>
> * If unqualified calls become always local, then every global function call
> needs a use statement or prefixing with "\".
> * If they become always global, then every local function call needs a use
> statement or prefixing with "namespace\".
>
> But the first option probably requires changes in the majority of PHP files
> in use anywhere; whereas the second only affects a small minority of code
> bases, and a small minority of code in those.
>
> 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.
>
> Unfortunately, finding unused syntax is hard, which is why we have "\" in the
> first place (and for the record, I think it works just fine), but maybe
> something like "_\" could work? Giving us:
>
> namespace Foo;
>
> $native_length = strlen('hello'); # same as \strlen('hello')
> $foo_length = _\strlen('hello'); # same as \Foo\strlen('hello')
>
If having to type `\strlen()` is ugly — and I agree that is it — then having to
type `_\strlen()` is what in university we would call "fugly," to emphasize
just how much worse something was vs. just run-of-the-mill "ugly."
Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR PREFERABLE to
_\strlen() because at least it provides satiating information rather than the
empty calories of a cryptic shorthand. #jmtcw, anyway.
> If I had a time machine, I'd campaign for "unqualified means local" in PHP
> 5.3, and we'd all be used to writing "\strlen" by now; but "unqualified means
> global" feels much more achievable from where we are.
>
If I had a time machine I would campaign for real packages instead of what
namespaces turned out to me, and that used sigils that do not double as the
escape character for strings, but then both of us digress.
-Mike
