The Daily Commit · Ressort-Ausgabe Titelseite PHP AI Dev EN DE FR ES

The Php Times

RFC-Watch — Ökosystem

Neuer RFC: Optionale Direktive für Namespace-Fallback in PHP


Paul M.

PHP INTERNALS ([RFC]/[VOTE]), 15. Juli 2026 kuratiert von Georg

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.

Originalquelle lesen (Englisch) ↗

Artikel bewerten: 0

Leserforum

Noch keine Beiträge — eröffne die Debatte.

← Ökosystem — Page B1

"All the Code That's Fit to Ship" · The Daily Commit · Bildschirm-Ausgabe · Impressum · Datenschutz