Nouveau RFC : une directive optionnelle pour le fallback de namespace en PHP
Paul M.
Jones a extrait le mécanisme `declare(strict_namespace=1)` du RFC sur l'autoloading de fonctions pour en faire une proposition indépendante. La directive permettrait de renoncer au fallback global pour les noms de fonctions et de constantes non qualifiés dans les namespaces. Destinée à atténuer le cas rare du « shadow global » dans l'autoloading de fonctions, elle suscite des débats sur son nom et son intérêt si l'ancien comportement n'est pas déprécié.
Paul M. Jones a extrait le concept `declare(strict_namespace=1)` du RFC sur l'autoloading de fonctions pour en faire une proposition indépendante intitulée "Strict Namespace Resolution". Le RFC est disponible à https://wiki.php.net/rfc/strict-namespace et est accompagné de la pull request https://github.com/php/php-src/pull/22736. Ce mécanisme est conçu comme une aide à l'initiative d'autoloading de fonctions, mais il n'en est pas une condition stricte.
La directive permettrait aux développeurs de renoncer au comportement de fallback actuel de PHP, où un nom de fonction ou de constante non qualifié dans un namespace est d'abord recherché dans le namespace courant, puis, s'il n'y est pas trouvé, dans le namespace global. Avec `declare(strict_namespace=1)` activé, ces références ne se résoudraient que dans le namespace déclaré, obligeant ainsi à importer explicitement ou à qualifier pleinement les symboles globaux.
La discussion sur la liste PHP internals a beaucoup porté sur le nom et la portée. Rowan Tommins a fait valoir que le libellé "strict_namespace" est trompeur, car la directive ne valide pas la correction des namespaces ; il a proposé des alternatives comme `legacy_name_fallback` ou trois modes explicites (global-only, current-namespace-only, fallback). Tim Düsterhus a suggéré `declare(global_fallback=0)` comme option plus claire, tandis qu'Alex Rock a évoqué `disable_root_ns_fallback=0|1`.
Ilija Tovilo a remis en question la valeur globale de la proposition si le fallback historique n'est jamais supprimé ou déprécié, notant que les utilisateurs qui optent pour la directive n'obtiennent rien qu'ils ne puissent déjà imposer avec un linter. Il a également esquissé un autre modèle dans lequel les noms non qualifiés renvoient toujours au symbole global, les symboles locaux étant accessibles via des imports `use` explicites. Paul M. Jones a répondu que la motivation principale reste d'atténuer le cas rare du « shadow global » dans l'autoloading de fonctions, et que la directive reste délibérément optionnelle.
Michael Morris a soulevé une préoccupation pratique concernant l'application de la directive à de nombreux fichiers sans avoir à l'ajouter en haut de chacun d'eux, ce que Rowan Tommins a qualifié de problème de conception plus profond de « package natif » ou de « module », dépassant le cadre de l'autoloading. Tim Düsterhus a également signalé que les analyseurs statiques et les EDI devraient reconnaître la directive pour émettre des diagnostics pertinents.
Des RFCs antérieures sur le même sujet ont également été mentionnées : « Fallback to root scope deprecation » de 2017, qui a été discuté mais jamais soumis au vote, et « use_global_elements » de 2020, qui a été rejeté.
Tribune des lecteurs
Pas encore de contributions — lance le débat.
Lance la discussion
Pas de compte ni de mot de passe — saisis simplement ton adresse e-mail et nous t’envoyons un lien de connexion à usage unique. Première visite ? Tout se met en place automatiquement.
Ton évaluation sera appliquée automatiquement après ta connexion.
Vérifie ta boîte mail
Nous avons envoyé un lien de connexion à …. Ouvre-le sur cet appareil — cet onglet te connectera automatiquement.
En attente de ton clic …
·