> On Aug 23, 2024, at 4:08 AM, Nick Lockheart <li...@ageofdream.com> wrote: > A third option, which I haven't seen come up on the list yet, is that > unqualified functions that are PHP built-ins are treated as global, and > using a function having the same name as a built-in, in a namespace > scope, requires a fully qualified name to override the built-in. > > It seems that if someone is writing `array_key_exists()` or similar > they probably mean the built-in function, and in the rare cases where > they do mean `\foo\array_key_exists()`, they can write it explicitly. > > Functions that are *not* on the built-in function list could default to > the local namespace.
I was going back and forth on this. On one hand it could be confusing for developers to learn when to use `\` and when not to. OTOH, once they learn it would create a clear indication of which functions are userland code and which are standard library, and I this could have significant benefit for readability and maintainability. Yet OTOH, this would create a bifurcation between userland and standard library that is encouraged in some languages and discouraged in others, i.e. the latter being the "keep the language as small as possible and then let the standard library be implemented in the language no differently than any code a user could write" type of languages. Yet OTOH still, PHP does not allow core functions to be implemented in userland, at least without monkey patching so the bifurcation already exists. Go, for example, has both. Most of the standard library is just Go code anyone could replace with their own, but a handful of functions are special and built into the language, e.g. append, new, close, etc. Basically anything in lowercase that can be used globally without qualification is special. And after using Go, I think it is a great design as it reserves future enhancements without BC concerns. In theory it would be nice to open up PHP to allow overriding core functions, but that could also open a Pandora's box, the kind that makes Ruby code so fragile. At least in Go you have to omit the standard lib import and use your own import to override a standard library package. So in practice PHP may never change to allow core functions to be overridden and thus pining for that to block this idea would be a missed opportunity. (That said, PHP could allow a userland function to be "registered" to be called instead of the core function, and if that were allowed then Nick's proposal would cause no problems. Of course I doubt internals would ever bless that idea.) Anyway — in summary — I think Nick's 3rd option has wings. And along with automatic `use` statements for each namespace might just be the best possible solution. -Mike P.S. If PHP ever added a set of standard library functions written in PHP to the core distribution, they should rightly IMO need to be namespaced, per this proposal. But here I digress. I only mention in hopes to keep this specific dream alive for some future day.
