Buschtrommel: PHP 8.4 und relevante Änderungen
Verfasst: 01.11.2024 14:02
Hallo Kollegen
Entgegen dem Themen-Präfix geht's hier nicht um Gerüchte, sondern um Fakten bezüglich kommender und relevanter Änderungen, die auch Erweiterungen Entwickler betreffen werden. Laut UPGRADE Doc von PHP 8.4-rc3 dürften Probleme bei den meisten Erweiterungen die schon für 8.3 geeignet sind, eher unwahrscheinlich sein. Es gibt jedoch 2 Änderungen die mir aufgefallen sind, die zukünftig relevant werden für uns, dazu ein Auszug aus dem besagten Dokument:
Um die Hintergründe besser verstehen zu können, einfach dem jeweiligen Link im Zitat folgen. Laut meiner Suche in meinem lokalen Erweiterungen Archiv, sind davon viele Erweiterungen betroffen, auch hier bei uns. Was
Beides wird ab 8.4 erstmal nur DEPRECATED Meldungen triggern, aber es ist durchaus sinnvoll, wenn man das frühzeitig anpasst. Solche Meldungen bekommt man nur, wenn der Debug Modus aktiv ist, was bei Entwickler aber ohnehin Standard ist bzw. sein sollte. Als "veraltet" eingestufte Features werden üblicherweise dann bei der nächsten Minor oder Major Version entfernt oder geändert und würden dann
edit 9.11.24: Das
Entgegen dem Themen-Präfix geht's hier nicht um Gerüchte, sondern um Fakten bezüglich kommender und relevanter Änderungen, die auch Erweiterungen Entwickler betreffen werden. Laut UPGRADE Doc von PHP 8.4-rc3 dürften Probleme bei den meisten Erweiterungen die schon für 8.3 geeignet sind, eher unwahrscheinlich sein. Es gibt jedoch 2 Änderungen die mir aufgefallen sind, die zukünftig relevant werden für uns, dazu ein Auszug aus dem besagten Dokument:
Quelle: https://github.com/php/php-src/blob/98c ... #L477-L481- Core:
. Implicitly nullable parameter types are now deprecated.
RFC: https://wiki.php.net/rfc/deprecate-impl ... able-types
. Passing E_USER_ERROR to trigger_error() is now deprecated.
RFC: https://wiki.php.net/rfc/deprecations_p ... gger_error
Um die Hintergründe besser verstehen zu können, einfach dem jeweiligen Link im Zitat folgen. Laut meiner Suche in meinem lokalen Erweiterungen Archiv, sind davon viele Erweiterungen betroffen, auch hier bei uns. Was
E_USER_ERROR
betrifft, so wird es auch bei phpBB selbst Änderungen geben müssen, da der Error Handler von phpBB direkt damit zu tun hat. Der Error Handler ist z.Z. sehr präsent für mich, wegen EMP 2.1.0, daher wusste ich das auch sofort.Beides wird ab 8.4 erstmal nur DEPRECATED Meldungen triggern, aber es ist durchaus sinnvoll, wenn man das frühzeitig anpasst. Solche Meldungen bekommt man nur, wenn der Debug Modus aktiv ist, was bei Entwickler aber ohnehin Standard ist bzw. sein sollte. Als "veraltet" eingestufte Features werden üblicherweise dann bei der nächsten Minor oder Major Version entfernt oder geändert und würden dann
E_ERROR
verursachen, mindestens aber E_WARNING
.edit 9.11.24: Das
trigger_error
Problem sollte klar sein, das andere ist aber nicht unbedingt selbsterklärend, darum hier meine Erklärung aus einem anderen Forum:
Nähere Erklärung zu "Implicitly nullable"
Der betroffene Code Block ist dieser hier:
Das Problem hier ist der Parameter
Implizit heisst hier, dass quasi angenommen wird, dass der Parameter auch
Hier haben wir definiert, dass der letzte Parameter optional ist und als Default
Jetzt geben wir explizit die Variablen-Typen vor und ab jetzt haben wir es auch mit dem implicite-nullable-Problem zu tun. Jetzt wird beim optionalen Parameter explizit ein
Jetzt haben wir EXPLIZIT folgendes für den optionalen Parameter definiert: Darf entweder ein
Die Lösung für das Problem im Konstruktor wäre also:
Ein simples ? direkt vor dem Variablentyp/Klasse und schon ist das Problem erledigt.
Siehe auch: Nullable-Typen
Code: Alles auswählen
public function __construct(
\phpbb\template\template $template,
\phpbb\collapsiblecategories\operator\operator $operator = null,
\phpbb\language\language $language
)
$operator
und dessen Default = null
. Das ist hier eine implicite nullable (implizit Null-bar) Deklaration. Das heisst, der Parameter darf entweder das Klassen-Objekt \phpbb\collapsiblecategories\operator\operator
enthalten, oder null
. Und genau diese implizite Deklaration ist ab 8.4 als veraltet eingestuft.Implizit heisst hier, dass quasi angenommen wird, dass der Parameter auch
null
sein darf. Und genau diese "Annahme" muss stattdessen durch eine explicite-nullable Deklaration ersetzt werden. Dazu erst ein kompakteres Beispiel:Code: Alles auswählen
function test($param_a, $param_b, $param_c = null)
{
// Hier machen wir irgendwas sinnvolles... oder auch nicht. ;-)
}
null
enthält. Bei diesem Code betrifft uns das implicite-nullable-Problem nicht, da hier keine strikte Typdeklaration vorhanden ist. Das heisst $param_c
kann "irgendeinen" Typ haben. Ganz anders sähe es so aus:Code: Alles auswählen
function test(string $param_a, bool $param_b, array $param_c = null)
{
// Hier machen wir irgendwas sinnvolles... oder auch nicht. ;-)
}
array
erwartet, aber es wird ausserdem implizit (indirekt) auch null
akzeptiert. Und genau das (implizit) mag PHP ab 8.4 nicht mehr und möchte es zukünftig (frühestens bei 8.5) ganz genau wissen. Um ein Variablentyp also auch als "nullable" (darf auch null
sein) deklarieren zu können, wird ein simples Fragezeichen (?) direkt vor der Typdeklaration benötigt. Das gibt es seit PHP 7.1. Demnach sähe die Lösung bei unserem kompakten Beispiel so aus:Code: Alles auswählen
function test(string $param_a, bool $param_b, ?array $param_c = null)
{
// Hier machen wir irgendwas sinnvolles... oder auch nicht. ;-)
}
array
oder null
sein, was anderes wird hier nicht akzeptiert. Und als Default wird auch gleich ein null
definiert.Die Lösung für das Problem im Konstruktor wäre also:
Code: Alles auswählen
public function __construct(
\phpbb\template\template $template,
?\phpbb\collapsiblecategories\operator\operator $operator = null,
\phpbb\language\language $language
)
Siehe auch: Nullable-Typen