> >
> >
> > 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 actually thinking of doing something like this for function
> autoloading, where extensions could register global functions that
> bypass the autoloader and go straight to global if it isn't defined
> in the local namespace already. I decided not to even bring it up
> because it felt controversial (it would effectively be global first,
> except for user functions). Though, it might be a nice compromise?
>
> — Rob
I think we are all trying to achieve the same thing here.
There's different ways to go about it, each with pros and cons, but I
think we need to think through how all the parts fit together, because
I think if we can reach consensus, then several RFCs become compatible
with each other.
A change to how function namespace lookup works would affect function
auto-loading, and it may even make it simpler, depending on the other
options that we end up going with.