The Daily Commit · Édition de rubrique La une PHP AI Dev EN DE FR ES

The Php Times

RFC Watch — Écosystème

Nouveau RFC : une directive optionnelle pour le fallback de namespace en PHP


Paul M.

PHP INTERNALS ([RFC]/[VOTE]), 15 juillet 2026 sélectionné par Georg

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é.

Lire la source originale (en anglais) ↗

Évaluer cet article : 0

Tribune des lecteurs

Pas encore de contributions — lance le débat.

← Écosystème — Page B1

"All the Code That's Fit to Ship" · The Daily Commit · Édition écran · Mentions légales · Politique de confidentialité