![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-released.png\")
Bist du bereit? Lasst uns eintauchen!<\/p>\n
PHP JIT (Just in Time Compiler)<\/h2>\n
Das am meisten gelobte Feature, das mit PHP 8 kommt, ist der Just-in-time (JIT) Compiler<\/strong>. Was hat es mit JIT auf sich?<\/p>\n Der RFC-Vorschlag beschreibt<\/a> JIT wie folgt:<\/p>\n „PHP JIT ist als ein fast unabh\u00e4ngiger Teil von OPcache implementiert. Es kann zur PHP-Kompilierzeit und zur Laufzeit aktiviert\/deaktiviert werden. Wenn es aktiviert ist, wird der native Code der PHP-Dateien in einer zus\u00e4tzlichen Region des OPcache-Shared Memory gespeichert und op_array\u2192opcodes[].handler(s) behalten Zeiger auf die Einstiegspunkte des JIT-ed-Codes.“<\/p><\/blockquote>\n Also, wie sind wir zu JIT gekommen und was ist der Unterschied zwischen JIT vs. OPcache?<\/p>\n Um besser zu verstehen, was JIT f\u00fcr PHP ist, wollen wir einen kurzen Blick darauf werfen, wie PHP<\/a> vom Quellcode bis zum Endergebnis ausgef\u00fchrt wird.<\/p>\n Die PHP-Ausf\u00fchrung ist ein 4-stufiger Prozess:<\/p>\n Das folgende Bild zeigt eine visuelle Darstellung des grundlegenden PHP-Ausf\u00fchrungsprozesses.<\/p>\n Also, wie macht OPcache PHP schneller? Und was \u00e4ndert sich im Ausf\u00fchrungsprozess mit JIT?<\/p>\n PHP ist eine interpretierte Sprache. Das bedeutet, wenn ein PHP-Skript l\u00e4uft, parst, kompiliert und f\u00fchrt der Interpreter den Code bei jeder Anfrage wieder und wieder aus. Dies kann zu einer Verschwendung von CPU-Ressourcen<\/a> und zus\u00e4tzlicher Zeit f\u00fchren.<\/p>\n Hier kommt die OPcache-Erweiterung<\/a> ins Spiel:<\/p>\n „OPcache verbessert die PHP-Leistung, indem vorkompilierter Skript-Bytecode im Shared Memory gespeichert wird, wodurch PHP nicht mehr bei jeder Anfrage Skripte laden und parsen muss.“<\/p><\/blockquote>\n Wenn OPcache aktiviert ist, durchl\u00e4uft der PHP-Interpreter den oben erw\u00e4hnten 4-Stufen-Prozess nur beim ersten Ausf\u00fchren des Skripts. Da PHP-Bytekodes im Shared Memory gespeichert werden, sind sie sofort als low-level Zwischendarstellung verf\u00fcgbar und k\u00f6nnen sofort auf der Zend VM ausgef\u00fchrt werden.<\/p>\n Ab PHP 5.5 ist die Zend OPcache-Erweiterung standardm\u00e4\u00dfig verf\u00fcgbar und du kannst \u00fcberpr\u00fcfen, ob du sie korrekt konfiguriert hast, indem du einfach Vorgeschlagene Lekt\u00fcre: Wie man die PHP-Speicherbegrenzung in WordPress verbessern kann.<\/a><\/p>\n OPcache wurde k\u00fcrzlich mit der Implementierung des Vorladens<\/a> verbessert, einer neuen OPcache-Funktion, die mit PHP 7.4<\/a> hinzugef\u00fcgt wurde. Das Vorladen bietet dir eine M\u00f6glichkeit, einen bestimmten Satz von Skripten im OPcache-Speicher zu speichern, „bevor irgendein Anwendungscode ausgef\u00fchrt wird“, aber es bringt keine greifbare Leistungsverbesserung f\u00fcr typische webbasierte Anwendungen.<\/p>\n Du kannst mehr \u00fcber das Vorladen in unserer Einf\u00fchrung zu PHP 7.4 lesen<\/a>.<\/p>\n Mit JIT geht PHP einen Schritt vorw\u00e4rts.<\/p>\n Auch wenn die Opcodes in Form von niedrigstufigen Zwischendarstellungen vorliegen, m\u00fcssen sie dennoch in Maschinencode \u00fcbersetzt werden. JIT „f\u00fchrt keine zus\u00e4tzliche IR (Intermediate Representation)-Form ein“, sondern verwendet DynASM<\/a> (Dynamic Assembler f\u00fcr Codegenerierungs-Engines), um nativen Code direkt aus dem PHP-Bytecode zu generieren.<\/p>\n Kurz gesagt, JIT \u00fcbersetzt die hei\u00dfen Teile des Zwischencodes in Maschinencode<\/strong>. Da es die Kompilierung umgeht, kann es erhebliche Verbesserungen der Leistung und des Speicherverbrauchs bringen.<\/p>\n Zeev Surasky, Co-Autor des PHP-JIT-Vorschlags, zeigt, um wie viel schneller Berechnungen mit JIT w\u00e4ren:<\/p>\n \u00a0<\/p>\n Aber, w\u00fcrde JIT die Leistung von WordPress<\/a> effektiv verbessern?<\/p>\n Laut dem JIT RFC sollte die just in time Compiler Implementierung die PHP Performance verbessern. Aber w\u00fcrden wir solche Verbesserungen wirklich in echten Anwendungen wie WordPress erleben?<\/p>\n Die fr\u00fchen Tests zeigen, dass JIT CPU-intensive Arbeitslasten deutlich schneller laufen lassen w\u00fcrde, warnt der RFC jedoch<\/a>:<\/p>\n „… wie bei den vorherigen Versuchen – es scheint derzeit keine signifikante Verbesserung von Real-Life-Anwendungen wie WordPress zu bringen (mit opcache.jit=1235 326 req\/sec vs 315 req\/sec).<\/p>\n Es ist geplant, dir zus\u00e4tzlichen Aufwand zu bieten, indem JIT f\u00fcr real-life Apps verbessert wird, mit Hilfe von Profiling und spekulativen Optimierungen“.<\/p><\/blockquote>\n Mit aktiviertem JIT w\u00fcrde der Code nicht von der Zend VM, sondern von der CPU selbst ausgef\u00fchrt werden, und das w\u00fcrde die Geschwindigkeit bei der Berechnung verbessern. Webanwendungen wie WordPress<\/a> h\u00e4ngen auch von anderen Faktoren wie TTFB<\/a>, Datenbankoptimierung<\/a>, HTTP-Anfragen<\/a>, etc. ab.<\/p>\n Also, wenn es um WordPress und \u00e4hnliche Anwendungen geht, sollten wir keine gro\u00dfe Steigerung der PHP-Ausf\u00fchrungsgeschwindigkeit erwarten. Nichtsdestotrotz k\u00f6nnte JIT den Entwicklern<\/a> einige Vorteile bringen.<\/p>\n Laut Nikita Popov:<\/a><\/p>\n „Die Vorteile des JIT-Compilers sind ungef\u00e4hr (und wie bereits im RFC beschrieben):<\/p>\n Also, w\u00e4hrend JIT kaum riesige Verbesserungen der WordPress-Performance bringen wird, wird es PHP auf die n\u00e4chste Stufe heben und es zu einer Sprache machen, in der viele Funktionen nun direkt geschrieben werden k\u00f6nnten.<\/p>\n Der Nachteil w\u00e4re allerdings die gr\u00f6\u00dfere Komplexit\u00e4t, die zu steigenden Kosten f\u00fcr Wartung<\/a>, Stabilit\u00e4t und Debugging<\/a> f\u00fchren kann. Laut Dmitry Stogov:<\/p>\n „JIT ist extrem einfach, aber trotzdem erh\u00f6ht es den Grad der gesamten PHP-Komplexit\u00e4t, das Risiko neuartiger Bugs und die Kosten f\u00fcr Entwicklung und Wartung.<\/p><\/blockquote>\n Der Vorschlag, JIT in PHP 8 aufzunehmen, wurde mit 50 zu 2 Stimmen angenommen.<\/p>\n\n Abgesehen von JIT, k\u00f6nnen wir viele Funktionen und Verbesserungen mit PHP 8 erwarten. Die folgende Liste ist unsere handverlesene Auswahl der kommenden Erg\u00e4nzungen und \u00c4nderungen, die PHP zuverl\u00e4ssiger und effizienter machen sollen.<\/p>\n Als Ergebnis einer andauernden Diskussion dar\u00fcber, wie man die Objekt-Ergonomie in PHP<\/a> verbessern kann, schl\u00e4gt der Constructor Property Promotion RFC<\/a> eine neue und pr\u00e4gnantere Syntax vor, die die Property-Deklaration vereinfacht und sie k\u00fcrzer und weniger \u00fcberfl\u00fcssig macht.<\/p>\n Dieser Vorschlag bezieht sich nur auf Promoted-Parameter<\/strong>, d.h. jene Methodenparameter, denen \u00f6ffentliche<\/strong>, gesch\u00fctzte<\/strong> und private<\/strong> Sichtbarkeits-Keywords vorangestellt werden.<\/p>\n Derzeit m\u00fcssen alle Eigenschaften mehrmals (mindestens viermal) wiederholt werden, bevor wir sie mit Objekten verwenden k\u00f6nnen. Betrachte das folgende Beispiel aus dem RFC:<\/p>\n Laut Nikita Popov, dem Autor des RFC, m\u00fcssen wir den Property-Namen mindestens viermal an drei verschiedenen Stellen schreiben: die Property-Deklaration, die Constructor-Parameter und die Property-Zuweisung. Diese Syntax ist nicht besonders brauchbar, vor allem in Klassen mit einer guten Anzahl von Eigenschaften und aussagekr\u00e4ftigeren Namen.<\/p>\n Dieser RFC schl\u00e4gt vor, den Konstruktor und die Parameterdefinition zusammenzuf\u00fchren. Ab PHP 8 haben wir also eine brauchbarere Art und Weise, Parameter zu deklarieren, und der oben programmierte Code kann sich wie unten gezeigt \u00e4ndern:<\/p>\n Und das war’s. Wir haben also einen neuen Weg, um Eigenschaften zu bewerben, der k\u00fcrzer, lesbarer und weniger fehleranf\u00e4llig ist. Laut Nikita<\/a>:<\/p>\n Es ist eine einfache syntaktische Umwandlung, die wir machen. Aber das reduziert die Menge an Boilerplate Code, den man vor allem f\u00fcr Wertobjekte schreiben muss.<\/p><\/blockquote>\n Die Eigenschaftsdeklaration wird transformiert, da wir diese Eigenschaften explizit deklariert haben, und wir k\u00f6nnen die Reflection-API<\/a> benutzen, um Eigenschaftsdefinitionen vor der Ausf\u00fchrung zu introspektieren (siehe Desugaring<\/a>):<\/p>\n Reflection (und andere Introspektionsmechanismen) werden den Zustand nach dem Desugaring beobachten. Das bedeutet, dass bef\u00f6rderte Eigenschaften genauso wie explizit deklarierte Eigenschaften erscheinen werden, und bef\u00f6rderte Konstruktor-Argumente werden wie gew\u00f6hnliche Konstruktor-Argumente erscheinen.<\/p><\/blockquote>\n Wir haben keine Einschr\u00e4nkungen bei der Verwendung von Vererbung in Verbindung mit Promotions-Parametern. Wie auch immer, es gibt keine besondere Beziehung zwischen Parent- und Child-Klassenkonstruktoren. Laut Nikita<\/a>:<\/p>\n Normalerweise sagen wir, dass Methoden immer mit der Parentmethode kompatibel sein m\u00fcssen. […] aber diese Regel gilt nicht f\u00fcr den Konstruktor. Der Konstruktor geh\u00f6rt also wirklich zu einer einzigen Klasse, und Konstruktoren zwischen Parent- und Child-Klasse m\u00fcssen in keiner Weise kompatibel sein.<\/p><\/blockquote>\n Hier ist ein Beispiel:<\/p>\n Promoted Eigenschaften sind in nicht-abstrakten Konstrukteuren und Eigenschaften erlaubt, aber es gibt einige Einschr\u00e4nkungen, die hier erw\u00e4hnt werden sollten.<\/p>\n Promoted Eigenschaften sind in abstrakten Klassen und Interfaces nicht erlaubt:<\/p>\n Eine der bemerkenswertesten Einschr\u00e4nkungen bezieht sich auf die Annullierbarkeit. Fr\u00fcher, wenn wir einen Typ benutzten, der nicht explizit l\u00f6schbar war, aber mit einem Standardwert von null, war der Typ implizit l\u00f6schbar. Aber bei Property-Typen haben wir dieses implizite Verhalten nicht, weil die Promoted-Parameter eine Property-Deklaration erfordern und der nullbare Typ explizit deklariert werden muss. Siehe das folgende Beispiel aus dem RFC:<\/p>\n Da Callable kein unterst\u00fctzter Typ f\u00fcr Eigenschaften ist<\/a>, ist es uns nicht erlaubt, den Callable-Typ in beworbenen Eigenschaften zu verwenden:<\/p>\n Nur ein visibility-Schl\u00fcsselwort kann mit promoted-Parametern verwendet werden, daher ist es nicht erlaubt, Konstruktoreigenschaften mit dem Wir k\u00f6nnen promoted Eigenschaften und explizite Eigenschaften in der gleichen Klasse kombinieren, aber Eigenschaften k\u00f6nnen nicht zweimal deklariert werden:<\/p>\n Der Grund daf\u00fcr ist, dass sich der deklarierte Typ von dem variadischen Parameter unterscheidet, der eigentlich ein Array ist:<\/p>\n Um einen genaueren Blick auf Costructor Property Promotion zu werfen, h\u00f6rt euch dieses Interview mit Nikita Popov an<\/a>. F\u00fcr einen tieferen Einblick in die Objekt-Ergonomie in PHP, schau dir diesen Beitrag<\/a> und das folgende Interview mit Larry Garfield<\/a> an.\u00a0<\/strong><\/p>\n Eigenschaften<\/a> werden definiert als „ein Mechanismus zur Wiederverwendung von Code in Sprachen mit einer einzigen Vererbung wie PHP“. Typischerweise werden sie verwendet, um Methoden zu deklarieren, die in mehreren Klassen verwendet werden k\u00f6nnen.<\/p>\n Eine Eigenschaft kann auch abstrakte Methoden enthalten. Diese Methoden deklarieren einfach die Signatur der Methode, aber die Implementierung der Methode muss innerhalb der Klasse unter Verwendung der Eigenschaft erfolgen.<\/p>\n Gem\u00e4\u00df dem PHP-Handbuch<\/a>,<\/p>\n „Eigenschaften unterst\u00fctzen die Verwendung abstrakter Methoden, um Anforderungen an die ausstellende Klasse zu stellen.\u201d<\/p><\/blockquote>\n Das bedeutet auch, dass die Signaturen der Methoden \u00fcbereinstimmen m\u00fcssen. Mit anderen Worten, die Art und die Anzahl der ben\u00f6tigten Argumente m\u00fcssen gleich sein<\/a>.<\/p>\n Wie auch immer, laut Nikita Popov<\/a>, Autor des RFC, wird die Signaturvalidierung derzeit nur punktuell durchgesetzt:<\/p>\n Das folgende Beispiel von Nikita bezieht sich auf den ersten Fall (nicht erzwungene Unterschrift):<\/p>\n Davon abgesehen schl\u00e4gt dieser RFC<\/a> vor, immer einen fatalen Fehler zu werfen, wenn die Implementierungsmethode nicht mit der abstrakten Eigenschaftsmethode kompatibel ist, unabh\u00e4ngig von ihrem Ursprung:<\/p>\n Dieser RFC wurde einstimmig angenommen.<\/p>\n In PHP werfen Vererbungsfehler aufgrund inkompatibler Methodensignaturen entweder einen fatalen Fehler oder eine Warnung aus, je nachdem, was die Ursache des Fehlers ist.<\/p>\n Wenn eine Klasse ein Interface implementiert, f\u00fchren inkompatible Methodensignaturen zu einem fatalen Fehler. Laut der Dokumentation zu Objekt Interfaces<\/a>:<\/p>\n „Die Klasse, die das Interface implementiert, muss eine Methodensignatur verwenden, die mit dem LSP (Liskov Substitutionsprinzip) kompatibel ist. Wenn sie dies nicht tut, f\u00fchrt dies zu einem fatalen Fehler.“<\/p><\/blockquote>\n Hier ist ein Beispiel f\u00fcr einen Vererbungsfehler mit einem Interface:<\/p>\n In PHP 7.4 w\u00fcrde der obige Code den folgenden Fehler ausl\u00f6sen:<\/p>\n Eine Funktion in einer Child-Klasse mit einer inkompatiblen Signatur w\u00fcrde eine Warnung ausl\u00f6sen. Siehe den folgenden Code aus dem RFC:<\/p>\n In PHP 7.4 w\u00fcrde der obige Code einfach eine Warnung ausgeben:<\/p>\n Nun schl\u00e4gt dieser RFC<\/a> vor, bei inkompatiblen Methodensignaturen immer einen fatalen Fehler zu werfen. Mit PHP 8 w\u00fcrde der Code, den wir weiter oben gesehen haben, folgendes ausl\u00f6sen:<\/p>\n In PHP, wenn ein Array mit einem negativen Index ( In PHP 7.4 w\u00fcrde das Ergebnis wie folgt aussehen:<\/p>\n Nun, dieser RFC<\/a> schl\u00e4gt vor, die Dinge so zu \u00e4ndern, dass der zweite Index In PHP 8 w\u00fcrde der obige Code zu folgendem Array f\u00fchren:<\/p>\n Mit PHP 8 \u00e4ndern Arrays, die mit einem negativen Index beginnen, ihr Verhalten. Lies mehr \u00fcber R\u00fcckw\u00e4rtsinkompatibilit\u00e4ten im RFC<\/a>.<\/p>\n Union types<\/a> akzeptieren Werte, die von unterschiedlicher Art sein k\u00f6nnen. Derzeit bietet PHP keine Unterst\u00fctzung f\u00fcr Union types, mit Ausnahme der Vor PHP 8 konnten Union types nur in phpdoc-Annotationen angegeben werden, wie das folgende Beispiel aus dem RFC zeigt:<\/p>\n Nun schl\u00e4gt der RFC f\u00fcr Union types 2.0<\/a> vor, Unterst\u00fctzung f\u00fcr Union types in Funktionssignaturen hinzuzuf\u00fcgen, so dass wir uns nicht mehr auf die Inline-Dokumentation verlassen, sondern stattdessen Union types mit einer Wie von Nikita Popov im RFC erkl\u00e4rt,<\/p>\n „Die Unterst\u00fctzung von Union-Types in der Sprache erlaubt es uns, mehr Typinformationen aus phpdoc in Funktionssignaturen zu verschieben, mit den \u00fcblichen Vorteilen, die das mit sich bringt:<\/p><\/blockquote>\n Union types unterst\u00fctzen alle verf\u00fcgbaren Typen, mit einigen Einschr\u00e4nkungen:<\/p>\n Mehr \u00fcber Union Types V2<\/a> k\u00f6nnt ihr im RFC nachlesen.<\/p>\n Wenn ein Parameter vom illegalen Typ \u00fcbergeben wird, verhalten sich interne<\/a> und benutzerdefinierte<\/a> Funktionen unterschiedlich.<\/p>\n Benutzerdefinierte Funktionen werfen einen Dies w\u00fcrde zu folgender Warnung f\u00fchren:<\/p>\n Wenn Diese Situation w\u00fcrde zu einer Reihe von Problemen f\u00fchren, die in der Issues-Sektion des RFC<\/a> gut erkl\u00e4rt sind.<\/p>\n Um diese Inkonsistenzen zu beseitigen, schl\u00e4gt dieser RFC vor<\/a>, die internen Parameter-Parsing-APIs so zu gestalten, dass sie immer einen In PHP 8 wirft der obige Code den folgenden Fehler aus:<\/p>\n In PHP ist Dieser RFC<\/a> schl\u00e4gt vor, die Siehe die folgenden Beispiele aus dem RFC:<\/p>\n Eine Weak Map ist eine Sammlung von Daten (Objekten), in der Schl\u00fcssel schwach referenziert werden, was bedeutet, dass sie nicht daran gehindert werden, M\u00fcll zu sammeln.<\/p>\n PHP 7.4 f\u00fcgte Unterst\u00fctzung f\u00fcr schwache Referenzen<\/a> hinzu, um einen Verweis auf ein Objekt zu erhalten, was nicht verhindert, dass das Objekt selbst zerst\u00f6rt wird. Wie von Nikita Popov angemerkt,<\/p>\n „Rohe schwache Verweise sind f\u00fcr sich genommen nur von begrenztem Nutzen und Weak Maps werden in der Praxis viel h\u00e4ufiger verwendet. Es ist nicht m\u00f6glich, eine effiziente Weak Map zus\u00e4tzlich zu den PHP-Schwachen Referenzen zu implementieren, da die M\u00f6glichkeit, einen Zerst\u00f6rungs-Callback zu registrieren, nicht angeboten wird.“<\/p><\/blockquote>\n Aus diesem Grund f\u00fchrt dieser RFC<\/a> eine In lang laufenden Prozessen w\u00fcrde dies Speicherlecks verhindern und die Performance verbessern. Siehe das folgende Beispiel aus dem RFC:<\/p>\n Mit PHP 8 w\u00fcrde der obige Code das folgende Ergebnis erzeugen (siehe den Code in Aktion hier)<\/a>:<\/p>\n Wenn du das Objekt entsperrst, wird der Schl\u00fcssel automatisch von der Weak Map entfernt:<\/p>\n Nun w\u00e4re das Ergebnis wie folgt:<\/p>\n F\u00fcr eine genauere Betrachtung der Weak Maps siehe RFC<\/a>. Der Vorschlag wurde einstimmig angenommen.<\/p>\n\n
![\"Grundlegender](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/05\/php-execution-1.png\")
Die OPcache-Erweiterung<\/h3>\n
![\"PHP-Ausf\u00fchrungsprozess](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/05\/php-execution-2.png\")
phpinfo()<\/code> von einem Skript auf deinem Server aufrufst<\/a> oder deine php.ini-Datei auscheckst (siehe OPcache-Konfigurationseinstellungen<\/a>).<\/p>\n![\"Zend](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/05\/zend-opcache.jpg\")
Vorladen<\/h3>\n
JIT \u2014 The Just in Time Compiler<\/h3>\n
JIT f\u00fcr Live Web Apps<\/h3>\n
![\"Relativer](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-performance-diagram.png\")
\n
PHP 8 Verbesserungen und neue Funktionen.<\/h2>\n
Constructor Property Promotion<\/h3>\n
class Point {\n public int $x;\n public int $y;\n public int $z;\n\n public function __construct(\n int $x = 0,\n int $y = 0,\n int $z = 0,\n ) {\n $this->x = $x;\n $this->y = $y;\n $this->z = $z;\n }\n}<\/code><\/pre>\nclass Point {\n public function __construct(\n public int $x = 0,\n public int $y = 0,\n public int $z = 0,\n ) {}\n}<\/code><\/pre>\n\/\/ before desugaring\nclass Point {\n public function __construct(public int $x = 0) {}\n}\n\n\/\/ after desugaring\nclass Point {\n public int $x;\n\n public function __construct(int $x = 0) {\n $this->x = $x;\n }\n}<\/code><\/pre>\nInheritance<\/h4>\n
class Test {\n public function __construct(\n public int $x = 0\n ) {}\n}\n\nclass Child extends Test {\n public function __construct(\n $x, \n public int $y = 0,\n public int $z = 0,\n ) {\n parent::__construct($x);\n }\n}<\/code><\/pre>\nWhat’s Not Allowed With Promoted Properties<\/h4>\n
Abstract Constructors<\/h5>\n
abstract class Test {\n \/\/ Error: Abstract constructor.\n abstract public function __construct(private $x);\n}\n \ninterface Test {\n \/\/ Error: Abstract constructor.\n public function __construct(private $x);\n}<\/code><\/pre>\nNullability<\/h5>\n
class Test {\n \/\/ Error: Using null default on non-nullable property\n public function __construct(public Type $prop = null) {}\n\n \/\/ Correct: Make the type explicitly nullable instead\n public function __construct(public ?Type $prop = null) {}\n}<\/code><\/pre>\nCallable Type<\/h5>\n
class Test {\n \/\/ Error: Callable type not supported for properties.\n public function __construct(public callable $callback) {}\n}<\/code><\/pre>\nThe var Keyword Is Not Allowed<\/h5>\n
var<\/code>-Schl\u00fcsselwort zu deklarieren (siehe das folgende Beispiel aus dem RFC):<\/p>\nclass Test {\n \/\/ Error: \"var\" keyword is not supported.\n public function __construct(var $prop) {}\n}<\/code><\/pre>\nNo Duplications Allowed<\/h5>\n
class Test {\n public string $prop;\n public int $explicitProp;\n\n \/\/ Correct\n public function __construct(public int $promotedProp, int $arg) {\n $this->explicitProp = $arg;\n }\n\n \/\/ Error: Redeclaration of property.\n public function __construct(public string $prop) {}\n}<\/code><\/pre>\nVariadic Parameters Are Not Allowed<\/h5>\n
class Test {\n \/\/ Error: Variadic parameter.\n public function __construct(public string ...$strings) {}\n}<\/code><\/pre>\nFurther Readings<\/h4>\n
Validierung f\u00fcr abstrakte Eigenschaftsmethoden<\/h3>\n
\n
trait T {\n\tabstract public function test(int $x);\n}\n \nclass C {\n\tuse T;\n\n\t\/\/ Allowed, but shouldn't be due to invalid type.\n\tpublic function test(string $x) {}\n}<\/code><\/pre>\nFatal error: Declaration of C::test(string $x) must be compatible with T::test(int $x) in \/path\/to\/your\/test.php on line 10<\/code><\/pre>\nInkompatible Methodensignaturen<\/h3>\n
interface I {\n\tpublic function method(array $a);\n}\nclass C implements I {\n\tpublic function method(int $a) {}\n}<\/code><\/pre>\nFatal error: Declaration of C::method(int $a) must be compatible with I::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nclass C1 {\n\tpublic function method(array $a) {}\n}\nclass C2 extends C1 {\n\tpublic function method(int $a) {}\n}<\/code><\/pre>\nWarning: Declaration of C2::method(int $a) should be compatible with C1::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nFatal error: Declaration of C2::method(int $a) must be compatible with C1::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nArrays, die mit einem negativen Index beginnen<\/h3>\n
start_index < 0<\/code>) beginnt, beginnen die folgenden Indizes bei 0 (mehr dazu in der array_fill<\/code> Dokumentation<\/a>). Schau dir das folgende Beispiel an:<\/p>\n$a = array_fill(-5, 4, true);\nvar_dump($a);<\/code><\/pre>\narray(4) {\n\t[-5]=>\n\tbool(true)\n\t[0]=>\n\tbool(true)\n\t[1]=>\n\tbool(true)\n\t[2]=>\n\tbool(true)\n}<\/code><\/pre>\nstart_index + 1<\/code> w\u00e4re, was auch immer der Wert von start_index<\/code> ist.<\/p>\narray(4) {\n\t[-5]=>\n\tbool(true)\n\t[-4]=>\n\tbool(true)\n\t[-3]=>\n\tbool(true)\n\t[-2]=>\n\tbool(true)\n}<\/code><\/pre>\nUnion Types 2.0<\/h3>\n
?Type<\/code> syntax und dem special iterable<\/code> type.<\/p>\nclass Number {\n\t\/**\n\t * @var int|float $number\n\t *\/\n\tprivate $number;\n\n\t\/**\n\t * @param int|float $number\n\t *\/\n\tpublic function setNumber($number) {\n\t\t$this->number = $number;\n\t}\n\n\t\/**\n\t * @return int|float\n\t *\/\n\tpublic function getNumber() {\n\t\treturn $this->number;\n\t}\n}<\/code><\/pre>\nT1|T2|...<\/code> Syntax definieren w\u00fcrden:<\/p>\nclass Number {\n\tprivate int|float $number;\n\n\tpublic function setNumber(int|float $number): void {\n\t\t$this->number = $number;\n\t}\n\n\tpublic function getNumber(): int|float {\n\t\treturn $this->number;\n\t}\n}<\/code><\/pre>\n\n
\n
void<\/code> kann nicht Teil einer Union sein, da void<\/code> bedeutet, dass eine Funktion keinen Wert zur\u00fcckgibt<\/a>.<\/li>\nnull<\/code>-Typ wird nur in Union types unterst\u00fctzt, aber seine Verwendung als eigenst\u00e4ndiger Typ ist nicht erlaubt.<\/li>\n?T<\/code>) ist auch erlaubt, was T|null<\/code> bedeutet, aber wir d\u00fcrfen die ?T<\/code>-Notation nicht in Union types verwenden (?T1|T2<\/code> ist nicht erlaubt und wir sollten stattdessen T1|T2|null<\/code> verwenden).<\/li>\nstrpos()<\/code>, strstr()<\/code>, substr()<\/code>, etc.) false<\/code> unter den m\u00f6glichen R\u00fcckgabetypen einschlie\u00dfen, wird auch der false<\/code> Pseudo-Typ unterst\u00fctzt.<\/li>\n<\/ul>\nKonsistente Typ-Fehler f\u00fcr interne Funktionen<\/h3>\n
TypeError<\/code>, aber interne Funktionen verhalten sich unterschiedlich, abh\u00e4ngig von verschiedenen Bedingungen. Wie auch immer, das typische Verhalten ist, eine Warnung zu werfen und null<\/code> zur\u00fcckzugeben. Siehe das folgende Beispiel in PHP 7.4:<\/p>\nvar_dump(strlen(new stdClass));<\/code><\/pre>\nWarning: strlen() expects parameter 1 to be string, object given in \/path\/to\/your\/test.php on line 4\nNULL<\/code><\/pre>\nstrict_types<\/code> aktiviert ist, oder argument information Typen angibt, w\u00e4re das Verhalten anders. In solchen Szenarien wird der Typfehler erkannt und f\u00fchrt zu einem TypeError<\/code>.<\/p>\nThrowError<\/code> erzeugen, wenn ein Parametertyp nicht \u00fcbereinstimmt.<\/p>\nFatal error: Uncaught TypeError: strlen(): Argument #1 ($str) must be of type string, object given in \/path\/to\/your\/test.php:4\nStack trace:\n#0 {main}\n thrown in \/path\/to\/your\/test.php on line 4<\/code><\/pre>\nthrow Expression<\/h3>\n
throw<\/code> eine Anweisung<\/a>, daher ist es nicht m\u00f6glich, sie an Stellen zu verwenden, an denen nur ein Ausdruck<\/a> erlaubt ist.<\/p>\nthrow<\/code>-Anweisung<\/a> in einen Ausdruck umzuwandeln, so dass sie in jedem Kontext verwendet werden kann, wo Ausdr\u00fccke erlaubt sind. Zum Beispiel arrow Funktionen<\/a>, Null-Koaleszenz-Operator<\/a>, tern\u00e4re und Elvis-Operatoren<\/a>, etc.<\/p>\n$callable = fn() => throw new Exception();\n\n\/\/ $value is non-nullable.\n$value = $nullableValue ?? throw new InvalidArgumentException();\n \n\/\/ $value is truthy.\n$value = $falsableValue ?: throw new InvalidArgumentException();<\/code><\/pre>\nWeak Maps<\/h3>\n
WeakMap<\/code>-Klasse ein, um Objekte zu erstellen, die als Weak Map-Schl\u00fcssel verwendet werden, die zerst\u00f6rt und von der Weak Map entfernt werden k\u00f6nnen, wenn es keine weiteren Referenzen auf das Schl\u00fcsselobjekt gibt.<\/p>\n$map = new WeakMap;\n$obj = new stdClass;\n$map[$obj] = 42;\nvar_dump($map);<\/code><\/pre>\nobject(WeakMap)#1 (1) {\n\t[0]=>\n\tarray(2) {\n\t\t[\"key\"]=>\n\t\tobject(stdClass)#2 (0) {\n\t\t}\n\t\t[\"value\"]=>\n\t\tint(42)\n\t}\n}<\/code><\/pre>\nunset($obj);\nvar_dump($map);<\/code><\/pre>\nobject(WeakMap)#1 (0) {\n}<\/code><\/pre>\n