The Php Times

Paul M. Jones ha separado el concepto `declare(strict_namespace=1)` del RFC sobre autoloading de funciones para crear una propuesta independiente titulada "Strict Namespace Resolution". El RFC está disponible en https://wiki.php.net/rfc/strict-namespace y va acompañado del pull request https://github.com/php/php-src/pull/22736. El mecanismo está pensado como apoyo a la iniciativa de autoloading de funciones, pero no es un requisito estricto para ella.

La directiva permitiría a los desarrolladores renunciar al comportamiento de fallback actual de PHP, por el cual un nombre de función o constante no calificado dentro de un namespace se busca primero en el namespace actual y, si no se encuentra, en el namespace global. Con `declare(strict_namespace=1)` activado, esas referencias solo se resolverían en el namespace declarado, lo que obligaría a importar explícitamente o a calificar completamente los símbolos globales.

La discusión en la lista de PHP internals se ha centrado en gran medida en el nombre y el alcance. Rowan Tommins argumentó que la etiqueta "strict_namespace" es confusa, ya que la directiva no valida la corrección de los namespaces; sugirió alternativas como `legacy_name_fallback` o tres modos explícitos (global-only, current-namespace-only, fallback). Tim Düsterhus propuso `declare(global_fallback=0)` como opción más clara, mientras que Alex Rock planteó `disable_root_ns_fallback=0|1`.

Ilija Tovilo cuestionó el valor general de la propuesta si el fallback histórico nunca se elimina o deprecia, señalando que quienes opten por la directiva no ganan nada que no pudieran ya imponer con un linter. También esbozó un diseño alternativo en el que los nombres no calificados siempre se refieren al símbolo global, accediendo a los símbolos locales mediante imports `use` explícitos. Paul M. Jones respondió que la motivación principal sigue siendo mitigar el caso raro del «shadow global» en el autoloading de funciones, y que la directiva sigue siendo deliberadamente opcional.

Michael Morris planteó una preocupación práctica sobre cómo aplicar la directiva en muchos archivos sin tener que colocarla al inicio de cada uno, lo que Rowan Tommins describió como un problema de diseño más profundo de «paquete nativo» o «módulo», que va más allá del autoloading. Tim Düsterhus también señaló que los analizadores estáticos y los IDE necesitarían reconocer la directiva para emitir diagnósticos útiles.

También se mencionaron RFCs previos sobre el mismo tema: «Fallback to root scope deprecation» de 2017, que se discutió pero nunca se sometió a voto, y «use_global_elements» de 2020, que fue rechazado.