Neuer RFC: Optionale Direktive für Namespace-Fallback in PHP
Paul M.
Jones hat den Mechanismus `declare(strict_namespace=1)` aus dem RFC zur Funktions-Autoloading in einen eigenen Vorschlag ausgegliedert. Die Direktive soll es ermöglichen, auf den globalen Fallback für unqualifizierte Funktions- und Konstantennamen innerhalb von Namespaces zu verzichten. Sie soll den seltenen Fall eines "Shadow Global" im Funktions-Autoloading abfedern, doch Internals-Mitglieder diskutieren den Namen der Direktive und ihren Nutzen, wenn das alte Verhalten nicht abgeschafft wird.
Paul M. Jones hat das Konzept `declare(strict_namespace=1)` aus dem RFC zum Funktions-Autoloading in einen eigenen Vorschlag mit dem Titel "Strict Namespace Resolution" ausgegliedert. Der RFC ist unter https://wiki.php.net/rfc/strict-namespace abrufbar und wird durch den Pull Request https://github.com/php/php-src/pull/22736 begleitet. Der Mechanismus soll das breitere Vorhaben des Funktions-Autoloadings unterstützen, ohne jedoch zwingend dafür erforderlich zu sein.
Die Direktive würde Entwicklern erlauben, sich von PHPs bestehendem Fallback-Verhalten abzumelden: Sucht ein unqualifizierter Funktions- oder Konstantenname innerhalb eines Namespace zunächst im aktuellen Namespace und anschließend, sofern nicht gefunden, im globalen Namespace. Mit aktivem `declare(strict_namespace=1)` würden derartige Referenzen nur noch im deklarierten Namespace aufgelöst, sodass globale Symbole explizit importiert oder vollständig qualifiziert werden müssten.
Die Diskussion auf der PHP-Internals-Liste drehte sich stark um Namensgebung und Umfang. Rowan Tommins argumentierte, die Bezeichnung "strict_namespace" sei irreführend, da die Direktive nicht die Korrektheit von Namespaces prüfe; er schlug Alternativen wie `legacy_name_fallback` oder drei explizite Modi (global-only, current-namespace-only, fallback) vor. Tim Düsterhus schlug `declare(global_fallback=0)` als klarere Option vor, während Alex Rock `disable_root_ns_fallback=0|1` ins Gespräch brachte.
Ilija Tovilo bezweifelte den Nutzen des Vorschlags, solange der alte Fallback nicht abgeschafft oder zumindest als veraltet markiert werde, und wies darauf hin, dass Nutzer, die die Direktive aktivieren, nichts gewinnen, was sie nicht bereits mit einem Linter erzwingen könnten. Er skizzierte zudem ein alternatives Design, bei dem unqualifizierte Namen stets auf globale Symbole verweisen und lokale Symbole über explizite `use`-Imports angesprochen werden. Paul M. Jones entgegnete, dass der Hauptantrieb weiterhin die Abschwächung des seltenen Falls eines "Shadow Global" im Funktions-Autoloading sei und die Direktive bewusst optional bleiben solle.
Michael Morris äußerte eine praktische Bedenken, wie sich die Direktive auf viele Dateien anwenden lasse, ohne sie in jeder einzelnen Datei einzufügen. Rowan Tommins bezeichnete dies als tieferliegendes Problem des "native package"- oder "module"-Designs, das über das Autoloading hinausgehe. Tim Düsterhus ergänzte, dass statische Analysewerkzeuge und IDEs die Direktive erkennen müssten, um sinnvolle Diagnosen ausgeben zu können.
Auch auf frühere RFCs zum gleichen Thema wurde verwiesen: "Fallback to root scope deprecation" aus dem Jahr 2017, das diskutiert, aber nie zur Abstimmung gebracht wurde, sowie "use_global_elements" aus dem Jahr 2020, das abgelehnt wurde.
Leserforum
Noch keine Beiträge — eröffne die Debatte.
Starte die Diskussion
Kein Konto, kein Passwort nötig — gib einfach deine E-Mail-Adresse ein, wir senden dir einen einmaligen Anmelde-Link. Beim ersten Mal bist du damit automatisch angemeldet.
Deine Bewertung wird nach der Anmeldung automatisch übernommen.
Schau in dein Postfach
Wir haben einen Anmelde-Link an … gesendet. Öffne ihn auf diesem Gerät — dieser Tab meldet dich automatisch an.
Warte auf deinen Klick …
·