{"id":851,"date":"2024-02-29T21:48:06","date_gmt":"2024-02-29T20:48:06","guid":{"rendered":"https:\/\/bsod.wtf\/?p=851"},"modified":"2024-03-01T09:44:04","modified_gmt":"2024-03-01T08:44:04","slug":"php-84-implizit-nullable-deprecation","status":"publish","type":"post","link":"https:\/\/bsod.wtf\/2024\/02\/29\/php-84-implizit-nullable-deprecation\/","title":{"rendered":"PHP 8.4: Implizite Nullable Parameter-Typen werden wohl deprecated"},"content":{"rendered":"\n
K\u00fcrzlich sahen die anstehenden \u00c4nderungen in PHP 8.4 noch vergleichsweise harmlos<\/a> aus. Doch jetzt steht etwas zur Abstimmung, das seinen Weg in PHP 8.4 finden soll und eine neue Deprecated-Meldung werfen k\u00f6nnte. Es geht um implizite Nullable Parameter-Typen. Der Vorschlag m\u00f6chte damit eine alte Karteileiche in der Sprache beheben, die seinerzeit als \u201enotwendiges \u00dcbel\u201c implementiert wurde \u2013 und nicht erst heute f\u00fcr Verwirrung sorgt.<\/p>\n\n\n\n Die RFC beschreibt genau<\/a>, was der Hintergrund der \u00c4nderung sein soll. Das \u201eProblem\u201c hei\u00dft Type Hinting. Damit kannst du im Code den Typ der Variable hinterlegen, die ein Parameter einer Funktion annehmen kann. Eine klassische PHP-Funktion k\u00f6nnte so aussehen:<\/p>\n\n\n Per se k\u00f6nnte Sp\u00e4ter kamen noch weitere Typen hinzu (5.4: Das ist jedoch wenig intuitiv und wird richtig ekelig, wenn eine solche Variable nicht am Ende steht. Dann sieht es n\u00e4mlich so aus, als k\u00f6nnte man den Parameter auch weglassen. Das ist jedoch nur erlaubt, wenn ausschlie\u00dflich optionale Parameter folgen. Deshalb wirft PHP entsprechend eine Warnung seit Version 8.0.<\/p>\n\n\n\n In PHP 7.1 wurde das Problem formell gel\u00f6st. Diese Version f\u00fchrte Nullable Typ-Deklarationen<\/a> ein. Sie werden mit einem Fragezeichen eingeleitet. Ab PHP 7.1 w\u00fcrde der Code also folgenderma\u00dfen aussehen (zum Vergleich auch im alten Syntax):<\/p>\n\n\n Der Vorschlag m\u00f6chte darauf hinaus, dass die erlaubten Datentypen f\u00fcr Parameter korrekt benannt werden und die alte Behelfsl\u00f6sung abschaffen. Das hat zudem den Vorteil, dass du zwar erlauben kannst<\/em>, dass Momentan findet bei PHP die Abstimmung statt, ob diese \u00c4nderung wirklich in die n\u00e4chste PHP-Version eingepflegt werden soll. Wie bei jeder RFC ist eine 2\/3-Mehrheit f\u00fcr eine Implementierung notwendig. Aktuell ist das Zwischenergebnis mit 14:1 f\u00fcr den Vorschlag ziemlich eindeutig. Die Abstimmung l\u00e4uft noch bis 13. M\u00e4rz 2024.<\/p>\n\n\n\n Da die alte \u201eL\u00f6sung\u201c gewisserma\u00dfen schon immer suboptimal war, die neue ab PHP 7.1 funktioniert und selbst PHP 7.1 l\u00e4ngst veraltet ist, solltest du also deinen Code nach derartigen Abominationen durchsuchen. Wirst du f\u00fcndig, solltest du das Fragezeichen setzen und den Standardwert Wenn der Vorschlag angenommen wird, wirft PHP andernfalls ab Version 8.4 eine Deprecated-Meldung. Die ist einmal unsch\u00f6n in den Logfiles und bedeutet au\u00dferdem, dass dein Code in PHP 9 gar nicht mehr funktioniert. Doch auch unabh\u00e4ngig vom Ausgang der Abstimmung solltest du die \u00c4nderungen vornehmen.<\/p>\n","protected":false},"excerpt":{"rendered":" K\u00fcrzlich sahen die anstehenden \u00c4nderungen in PHP 8.4 noch vergleichsweise harmlos aus. Doch jetzt steht etwas zur Abstimmung, das seinen Weg in PHP 8.4 finden soll und eine neue Deprecated-Meldung werfen k\u00f6nnte. Es geht um implizite Nullable Parameter-Typen. Der Vorschlag m\u00f6chte damit eine alte Karteileiche in der Sprache beheben, die seinerzeit als \u201enotwendiges \u00dcbel\u201c implementiert … Weiterlesen …<\/a><\/p>\n","protected":false},"author":1,"featured_media":849,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_metis_text_type":"standard","_metis_text_length":3555,"_post_count":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[13],"class_list":["post-851","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bsod","tag-php"],"acf":[],"yoast_head":"\nWorum geht es?<\/h2>\n\n\n\n
\nfunction foo($variable) {}\n<\/pre><\/div>\n\n\n
$variable<\/code> von einem beliebigen Typ sein. Seit PHP 5.1 kannst du PHP mitteilen, dass
$variable<\/code> vom Typ
array<\/code> sein muss:<\/p>\n\n\n
\nfunction foo(array $variable) {}\n<\/pre><\/div>\n\n\n
callable<\/code>, 7.0: skalare, also
int<\/code>,
float<\/code> und so weiter). PHP hat es jedoch erlaubt, dass
$variable<\/code> auch
null<\/code> sein darf \u2013 wenn du einen \u201eStandardwert\u201c auf
null<\/code> setzt. Dann s\u00e4he der Code so aus:<\/p>\n\n\n
\nfunction foo(array $variable = null) {}\n<\/pre><\/div>\n\n\n
\n\/\/ PHP 5.1+, Deprecation-Meldung in 8.4\nfunction foo_php51(array $variable = null) {}\nfoo_php51(null); \/\/ erlaubt\nfoo_php51(); \/\/ ebenfalls erlaubt, $variable wird als null (Standardwert) angenommen\n\n\/\/ PHP 7.1+\nfunction foo_php71(?array $variable) {}\nfoo_php71(null); \/\/ erlaubt ab 7.1, auch in 8.4\nfoo_php71(); \/\/ Fehler, weil Pflicht-Parameter nicht gesetzt ist\n<\/pre><\/div>\n\n\n
$variable = null<\/code> wird, aber das nicht der Standardwert sein muss, falls kein Parameter angegeben ist. Du kannst ihn also als notwendigen Parameter definieren.<\/p>\n\n\n\n
Abstimmung f\u00fcr PHP 8.4 findet statt<\/h2>\n\n\n\n
= null<\/code> nur dann drin lassen, wenn es wirklich gew\u00fcnscht ist, dass der Parameter weggelassen werden darf und dann als
null<\/code> in der Funktion verwendet wird.<\/p>\n\n\n\n