Was ist neu in PHP 8.2 – Neue Funktionen, Verwerfungen, Änderungen und mehr

PHP 8.2 baut auf der erneuerten Basis von PHP 8.0 und PHP 8.1 auf. Die Veröffentlichung ist für den 24. November 2022 geplant.

In diesem Artikel werden die Neuerungen in PHP 8.2 im Detail behandelt – von den neuen Funktionen und Verbesserungen bis hin zu Verwerfungen und kleineren Änderungen werden wir sie alle durchgehen.

Da PHP 8.2 am 19. Juli 2022 in den Feature-Freeze eingetreten ist, können Sie keine wesentlichen Ergänzungen dieser Liste erwarten.

Aufgeregt? Waren auch.

Lass uns anfangen!

Neue Funktionen und Verbesserungen in PHP 8.2

Beginnen wir damit, die neuesten Funktionen von PHP 8.2 zu erkunden. Es ist eine ziemlich umfangreiche Liste:

Neue readonly Klassen

PHP 8.1 hat die readonly Funktion für Klasseneigenschaften eingeführt. Jetzt fügt PHP 8.2 Unterstützung hinzu, um die gesamte Klasse als readonly zu deklarieren.

Wenn Sie eine Klasse als readonly , erben alle ihre Eigenschaften automatisch die readonly Funktion. Daher ist das Deklarieren einer Klasse readonly dasselbe wie das Deklarieren jeder Klasseneigenschaft als readonly .

Bei PHP 8.1 mussten Sie beispielsweise diesen langwierigen Code schreiben, um alle Klasseneigenschaften als readonly zu deklarieren:

 class MyClass { public readonly string $myValue, public readonly int $myOtherValue public readonly string $myAnotherValue public readonly int $myYetAnotherValue }

Stellen Sie sich dasselbe mit vielen weiteren Eigenschaften vor. Jetzt, mit PHP 8.2, können Sie einfach Folgendes schreiben:

 readonly class MyClass { public string $myValue, public int $myOtherValue public string $myAnotherValue public int $myYetAnotherValue }

Sie können abstrakte oder endgültige Klassen auch als readonly . Dabei spielt die Reihenfolge der Keywords keine Rolle.

 abstract readonly class Free {} final readonly class Dom {}

Sie können auch eine readonly Klasse ohne Eigenschaften deklarieren. Effektiv verhindert dies dynamische Eigenschaften, während es untergeordneten Klassen weiterhin erlaubt, ihre readonly Eigenschaften explizit zu deklarieren.

Als Nächstes können readonly Klassen nur typisierte Eigenschaften enthalten – dieselbe Regel für das Deklarieren einzelner schreibgeschützter Eigenschaften.

Sie können die mixed Eigenschaft verwenden, wenn Sie keine strikt typisierte Eigenschaft deklarieren können.

Der Versuch, eine readonly Klasse ohne eine typisierte Eigenschaft zu deklarieren, führt zu einem schwerwiegenden Fehler:

 readonly class Type { public $nope; } Fatal error: Readonly property Type::$nope must have type in ... on line ...

Außerdem können Sie bestimmte PHP-Funktionen nicht readonly deklarieren:

• Aufzählungen (da sie keine Eigenschaft enthalten können)
• Züge
• Schnittstellen

Der Versuch, eine dieser Funktionen als readonly zu deklarieren, führt zu einem Parse-Fehler.

 readonly interface Destiny {} Parse error: syntax error, unexpected token "interface", expecting "abstract" or "final" or "readonly" or "class" in ... on line ...

Wie bei allen PHP-Schlüsselwörtern wird beim readonly Schlüsselwort die Groß- und Kleinschreibung nicht beachtet.

PHP 8.2 missbilligt auch dynamische Eigenschaften (dazu später mehr). Sie können jedoch nicht verhindern, dass einer Klasse dynamische Eigenschaften hinzugefügt werden. Wenn Sie dies jedoch für eine readonly Klasse tun, führt dies nur zu einem schwerwiegenden Fehler.

 Fatal error: Readonly property Test::$test must have type in ... on line ...

Erlauben Sie true , false und null als eigenständige Typen

PHP enthält bereits skalare Typen wie int , string und bool . Dies wurde in PHP 8.0 durch das Hinzufügen von Union-Typen erweitert, sodass Werte von unterschiedlichen Typen sein können. Derselbe RFC erlaubte auch die Verwendung von false und null als Teil eines Union-Typs – sie waren jedoch nicht als eigenständige Typen zulässig.

Wenn Sie versucht haben, false oder null oder als eigenständige Typen zu deklarieren – ohne dass sie Teil eines Union-Typs sind – führte dies zu einem schwerwiegenden Fehler.

 function spam(): null {} function eggs(): false {} Fatal error: Null can not be used as a standalone type in ... on line ... Fatal error: False can not be used as a standalone type in ... on line ...

Um dieses Szenario zu vermeiden, fügt PHP 8.2 Unterstützung für die Verwendung von false und null als eigenständige Typen hinzu. Mit dieser Ergänzung ist das Typsystem von PHP ausdrucksstärker und vollständiger. Sie können jetzt die Rückgabe-, Parameter- und Eigenschaftstypen genau deklarieren.

Außerdem enthält PHP immer noch keinen true Typ, der ein natürliches Gegenstück zum false Typ zu sein scheint. PHP 8.2 behebt das und fügt auch Unterstützung für den true Typ hinzu. Es erlaubt keinen Zwang, genau wie sich der false Typ verhält.

Sowohl true als auch false Typen sind im Wesentlichen ein Union-Typ des bool -Typs von PHP. Um Redundanz zu vermeiden, können Sie diese drei Typen nicht zusammen in einem Union-Typ deklarieren. Dies führt zu einem schwerwiegenden Fehler bei der Kompilierung.

Disjunktive Normalform (DNF) Typen

Die disjunktive Normalform (DNF) ist eine standardisierte Art, boolesche Ausdrücke zu organisieren. Es besteht aus einer Disjunktion von Konjunktionen – boolesch ausgedrückt ist das ein ODER von UND .

Das Anwenden von DNF auf Typdeklarationen ermöglicht eine Standardmethode zum Schreiben kombinierter Union- und Intersection-Typen, die der Parser verarbeiten kann. Die neue Funktion für DNF-Typen von PHP 8.2 ist einfach, aber leistungsstark, wenn sie richtig verwendet wird.

Der RFC gibt das folgende Beispiel. Es wird davon ausgegangen, dass die folgenden Schnittstellen- und Klassendefinitionen bereits vorhanden sind:

 interface A {} interface B {} interface C extends A {} interface D {} class W implements A {} class X implements B {} class Y implements A, B {} class Z extends Y implements C {}

Mit DNF-Typen können Sie Typdeklarationen für Eigenschaften, Parameter und Rückgabewerte wie folgt durchführen:

 // Accepts an object that implements both A and B, // OR an object that implements D (A&B)|D // Accepts an object that implements C, // OR a child of X that also implements D, // OR null C|(X&D)|null // Accepts an object that implements all three of A, B, and D, // OR an int, // OR null. (A&B&D)|int|null

In einigen Fällen befinden sich die Eigenschaften möglicherweise nicht in DNF-Formularen. Werden sie als solche deklariert, führt dies zu einem Parsing-Fehler. Aber Sie können sie jederzeit umschreiben als:

 A&(B|D) // Can be rewritten as (A&B)|(A&D) A|(B&(D|W)|null) // Can be rewritten as A|(B&D)|(B&W)|null

Beachten Sie, dass jedes Segment eines DNF-Typs eindeutig sein muss. Beispielsweise ist die Deklaration von (A&B)|(B&A) ungültig, da die beiden ODER- verknüpften Segmente logisch gleich sind.

Hinzu kommt, dass Segmente, die strikte Teilmengen des anderen Segments sind, ebenfalls nicht zulässig sind. Das liegt daran, dass die Obermenge bereits alle Instanzen der Untermenge enthält, wodurch die Verwendung von DNF überflüssig wird.

Schwärzen Sie sensible Parameter in Rückverfolgungen

Wie fast jede Programmiersprache ermöglicht PHP das Verfolgen seines Aufrufstapels an jedem Punkt der Codeausführung. Stack Tracing erleichtert das Debuggen von Code, um Fehler und Leistungsengpässe zu beheben. Es bildet das Rückgrat von Tools wie Kinsta APM, unserem maßgeschneiderten Leistungsüberwachungstool für WordPress-Sites.

Das Durchführen eines Stack-Trace hält die Ausführung des Programms nicht an. Typischerweise laufen die meisten Stack-Traces im Hintergrund und werden im Hintergrund protokolliert – für eine spätere Überprüfung, falls erforderlich.

Einige dieser detaillierten PHP-Stack-Traces können jedoch ein Nachteil sein, wenn Sie sie mit Diensten von Drittanbietern teilen – normalerweise zur Fehlerprotokollanalyse, Fehlerverfolgung usw. Diese Stack-Traces können vertrauliche Informationen wie Benutzernamen, Passwörter und Umgebungsvariablen enthalten .

Dieser RFC-Vorschlag gibt ein solches Beispiel:

Ein häufiger „Täter“ ist PDO, das das Datenbankpasswort als Konstruktorparameter nimmt und sofort versucht, sich mit der Datenbank innerhalb des Konstruktors zu verbinden, anstatt einen reinen Konstruktor und eine separate Methode ->connect() zu haben. Wenn also die Datenbankverbindung fehlschlägt, enthält der Stack-Trace das Datenbankkennwort:

 PDOException: SQLSTATE[HY000] [2002] No such file or directory in /var/www/html/test.php:3 Stack trace: #0 /var/www/html/test.php(3): PDO->__construct('mysql:host=loca...', 'root', 'password') #1 {main}

PHP 8.2 ermöglicht es Ihnen, solche sensiblen Parameter mit einem neuen \SensitiveParameter Attribut zu markieren. Alle als sensibel gekennzeichneten Parameter werden nicht in Ihren Backtraces aufgeführt. Sie können sie also bedenkenlos mit Diensten von Drittanbietern teilen.

Hier ist ein einfaches Beispiel mit einem einzigen sensiblen Parameter:

 <?php function example( $ham, #[\SensitiveParameter] $eggs, $butter ) { throw new \Exception('Error'); } example('ham', 'eggs', 'butter'); /* Fatal error: Uncaught Exception: Error in test.php:8 Stack trace: #0 test.php(11): test('ham', Object(SensitiveParameterValue), 'butter') #1 {main} thrown in test.php on line 8 */

Wenn Sie einen Backtrace generieren, wird jeder Parameter mit dem \SensitiveParameter Attribut durch ein \SensitiveParameterValue Objekt ersetzt, und sein realer Wert wird nie im Trace gespeichert. Das SensitiveParameterValue Objekt kapselt den tatsächlichen Parameterwert – falls Sie ihn aus irgendeinem Grund benötigen.

Neue mysqli_execute_query -Funktion und mysqli::execute_query Methode

Haben Sie jemals die Funktion mysqli_query() mit gefährlich maskierten Benutzerwerten verwendet, nur um eine parametrisierte MySQLi-Abfrage auszuführen?

PHP 8.2 vereinfacht die Ausführung parametrisierter MySQLi-Abfragen mit der neuen mysqli_execute_query($sql, $params) und der Methode mysqli::execute_query .

Im Wesentlichen ist diese neue Funktion eine Kombination der Funktionen mysqli_prepare() , mysqli_execute() und mysqli_stmt_get_result() . Damit wird die MySQLi-Abfrage vorbereitet, gebunden (falls Sie Parameter übergeben) und innerhalb der Funktion selbst ausgeführt. Wenn die Abfrage erfolgreich ausgeführt wird, gibt sie ein mysqli_result Objekt zurück. Wenn dies nicht erfolgreich ist, wird false zurückgegeben.

Der RFC-Vorschlag gibt ein einfaches, aber leistungsstarkes Beispiel:

 foreach ($db->execute_query('SELECT * FROM user WHERE name LIKE ? AND type_id IN (?, ?)', [$name, $type1, $type2]) as $row) { print_r($row); }

enum in const Ausdrücken abrufen

Dieser RFC schlägt vor, dem Operator ->/?-> zu erlauben, enum in const Ausdrücken abzurufen.

Der Hauptgrund für diese neue Funktion ist, dass Sie an einigen Stellen keine enum -Objekte verwenden können, wie z. B. Array-Schlüssel. In einem solchen Fall müssen Sie den Wert des enum Falls wiederholen, um ihn zu verwenden.

Das Abrufen von enum an Orten zuzulassen, an denen enum nicht zulässig sind, kann dieses Verfahren vereinfachen.

Das bedeutet, dass der folgende Code jetzt gültig ist:

 const C = [self::B->value => self::B];

Und nur um sicherzugehen, enthält dieser RFC auch Unterstützung für den nullsafe-Operator ?-> .

Konstanten in Merkmalen zulassen

PHP enthält eine Möglichkeit zur Wiederverwendung von Code namens Traits. Sie eignen sich hervorragend für die klassenübergreifende Wiederverwendung von Code.

Derzeit erlauben Traits nur das Definieren von Methoden und Eigenschaften, aber keine Konstanten. Das bedeutet, dass Sie keine Invarianten definieren können, die von einem Merkmal innerhalb des Merkmals selbst erwartet werden. Um diese Einschränkung zu umgehen, müssen Sie Konstanten in ihrer Kompositionsklasse oder einer von ihrer Kompositionsklasse implementierten Schnittstelle definieren.

Dieser RFC schlägt vor, die Definition von Konstanten in Traits zuzulassen. Diese Konstanten können genau so definiert werden, wie Sie Klassenkonstanten definieren würden. Dieses Beispiel direkt aus dem RFC klärt die Luft um seine Verwendung:

 trait Foo { public const FLAG_1 = 1; protected const FLAG_2 = 2; private const FLAG_3 = 2; public function doFoo(int $flags): void { if ($flags & self::FLAG_1) { echo 'Got flag 1'; } if ($flags & self::FLAG_2) { echo 'Got flag 2'; } if ($flags & self::FLAG_3) { echo 'Got flag 3'; } } }

Eigenschaftskonstanten werden ebenfalls in die Definition der zusammengesetzten Klasse eingefügt, genauso wie die Eigenschafts- und Methodendefinitionen einer Eigenschaft. Sie haben auch ähnliche Einschränkungen wie Eigenschaften von Eigenschaften. Wie im RFC angemerkt, erfordert dieser Vorschlag – obwohl er ein guter Anfang ist – weitere Arbeit, um das Feature zu konkretisieren.

Verwerfungen in PHP 8.2

Wir können jetzt alle Verwerfungen in PHP 8.2 untersuchen. Diese Liste ist nicht ganz so groß wie die neuen Features:

Dynamische Eigenschaften verwerfen (und neues Attribut #[AllowDynamicProperties] )

Bis PHP 8.1 konnten Sie nicht deklarierte Klasseneigenschaften in PHP dynamisch setzen und abrufen. Zum Beispiel:

 class Post { private int $pid; } $post = new Post(); $post->name = 'Kinsta';

Hier deklariert die Post -Klasse keine name . Da PHP jedoch dynamische Eigenschaften zulässt, können Sie diese außerhalb der Klassendeklaration festlegen. Das ist sein größter – und möglicherweise einziger – Vorteil.

Dynamische Eigenschaften lassen unerwartete Fehler und unerwartetes Verhalten in Ihrem Code zu. Wenn Sie beispielsweise beim Deklarieren einer Klasseneigenschaft außerhalb der Klasse einen Fehler machen, können Sie leicht den Überblick verlieren – insbesondere beim Debuggen von Fehlern innerhalb dieser Klasse.

Ab PHP 8.2 sind dynamische Eigenschaften veraltet. Beim Festlegen eines Werts für eine nicht deklarierte Klasseneigenschaft wird beim erstmaligen Festlegen der Eigenschaft eine Verfallsbenachrichtigung ausgegeben.

 class Foo {} $foo = new Foo; // Deprecated: Creation of dynamic property Foo::$bar is deprecated $foo->bar = 1; // No deprecation warning: Dynamic property already exists. $foo->bar = 2;

Ab PHP 9.0 wird jedoch das Setzen desselben einen ErrorException -Fehler auslösen.

Wenn Ihr Code voller dynamischer Eigenschaften ist – und das ist viel PHP-Code – und wenn Sie diese Verfallshinweise nach dem Upgrade auf PHP 8.2 stoppen möchten, können Sie das neue #[AllowDynamicProperties] -Attribut von PHP 8.2 verwenden, um dynamische Eigenschaften zuzulassen Eigenschaften auf Klassen.

 #[AllowDynamicProperties] class Pets {} class Cats extends Pets {} // You'll get no deprecation warning $obj = new Pets; $obj->test = 1; // You'll get no deprecation warning for child classes $obj = new Cats; $obj->test = 1;

Gemäß RFC können Klassen, die als #[AllowDynamicProperties] gekennzeichnet sind, sowie ihre untergeordneten Klassen weiterhin dynamische Eigenschaften verwenden, ohne dass sie veraltet oder entfernt werden.

Sie sollten auch beachten, dass in PHP 8.2 die einzige gebündelte Klasse, die als #[AllowDynamicProperties] gekennzeichnet ist stdClass ist. Darüber hinaus werden alle Eigenschaften, auf die über die magischen PHP-Methoden __get() oder __set() zugegriffen wird, nicht als dynamische Eigenschaften betrachtet, sodass sie keine Verfallsbenachrichtigung auslösen.

Verwerfen Sie teilweise unterstützte Callables

Eine weitere Änderung von PHP 8.2, wenn auch mit vernachlässigbareren Auswirkungen, besteht darin, teilweise unterstützte Callables zu verwerfen.

Diese Callables werden als teilweise unterstützt bezeichnet, da Sie nicht direkt über $callable() mit ihnen interagieren können. Sie können sie nur mit der Funktion call_user_func($callable) . Die Liste solcher Callables ist nicht lang:

 "self::method" "parent::method" "static::method" ["self", "method"] ["parent", "method"] ["static", "method"] ["Foo", "Bar::method"] [new Foo, "Bar::method"]

Ab PHP 8.2 wird bei allen Versuchen, solche Callables aufzurufen – etwa über die Funktionen call_user_func() oder array_map() – eine Verfallswarnung ausgegeben.

Der ursprüngliche RFC liefert eine solide Begründung für diese Ablehnung:

Abgesehen von den letzten beiden Fällen sind alle diese Callables kontextabhängig. Auf welche Methode sich "self::method" bezieht, hängt davon ab, von welcher Klasse aus der Aufruf oder die Callability-Prüfung durchgeführt wird. In der Praxis gilt dies normalerweise auch für die letzten beiden Fälle, wenn sie in Form von [new Foo, "parent::method"] .

Die Reduzierung der Kontextabhängigkeit von Callables ist das sekundäre Ziel dieses RFC. Nach diesem RFC ist die einzige noch verbleibende Bereichsabhängigkeit die Methodensichtbarkeit: "Foo::bar" kann in einem Bereich sichtbar sein, aber nicht in einem anderen. Wenn Callables in Zukunft auf öffentliche Methoden beschränkt würden (während private Methoden erstklassige Callables verwenden oder Closure::fromCallable() Scope-unabhängig machen müssten), dann würde der Callable Type wohldefiniert werden und könnte als Eigenschaftstyp verwendet werden. Änderungen an der Handhabung der Sichtbarkeit werden jedoch nicht als Teil dieses RFC vorgeschlagen .

Gemäß dem ursprünglichen RFC akzeptieren die Funktion is_callable() und der callable Typ diese aufrufbaren Elemente weiterhin als Ausnahmen. Aber nur, bis die Unterstützung für sie ab PHP 9.0 vollständig entfernt wird.

Um Verwirrung zu vermeiden, wurde dieser Geltungsbereich für veraltete Hinweise mit einem neuen RFC erweitert – er enthält jetzt diese Ausnahmen.

Es ist gut zu sehen, dass sich PHP in Richtung eines gut definierten callable Typs bewegt.

Verwerfen Sie die Funktionen #utf8_encode() und utf8_decode()

Die in PHP integrierten Funktionen utf8_encode() und utf8_decode() konvertieren Zeichenfolgen, die in ISO-8859-1 („Latin 1“) codiert sind, nach und von UTF-8.

Ihre Namen legen jedoch eine allgemeinere Verwendung nahe, als ihre Implementierung zulässt. Die Codierung „Latin 1“ wird häufig mit anderen Codierungen wie der „Windows Code Page 1252“ verwechselt.

Außerdem sehen Sie normalerweise Mojibake, wenn diese Funktionen keine Zeichenfolge richtig konvertieren können. Das Fehlen von Fehlermeldungen bedeutet auch, dass es schwierig ist, sie zu erkennen, insbesondere in einem Meer von ansonsten lesbarem Text.

PHP 8.2 veraltet sowohl die Funktionen #utf8_encode() als utf8_decode() . Wenn Sie sie aufrufen, sehen Sie diese Verfallshinweise:

 Deprecated: Function utf8_encode() is deprecated Deprecated: Function utf8_decode() is deprecated

Der RFC schlägt vor, stattdessen die von PHP unterstützten Erweiterungen wie mbstring , iconv und intl zu verwenden.

Verwerfen Sie die ${} String-Interpolation

PHP erlaubt das Einbetten von Variablen in Strings mit doppelten Anführungszeichen ( " ) und Heredoc ( <<< ) auf verschiedene Arten:

1. Variablen direkt einbetten – “$foo”
2. Mit geschweiften Klammern außerhalb der Variablen — “{$foo}”
3. Mit geschweiften Klammern nach dem Dollarzeichen – “${foo}”
4. Variable Variablen – “${expr}” – entspricht der Verwendung von (string) ${expr}

Die ersten beiden Möglichkeiten haben ihre Vor- und Nachteile, während die beiden letzteren eine komplexe und widersprüchliche Syntax haben. PHP 8.2 missbilligt die letzten beiden Möglichkeiten der String-Interpolation.

Sie sollten sich in Zukunft von der Interpolation von Zeichenfolgen auf diese Weise fernhalten:

 "Hello, ${world}!"; Deprecated: Using ${} in strings is deprecated "Hello, ${(world)}!"; Deprecated: Using ${} (variable variables) in strings is deprecated

Beginnend mit PHP 9.0 werden diese Verwerfungen aktualisiert, um einen Ausnahmefehler auszulösen.

mbstring-Funktionen für Base64/QPrint/Uuencode/HTML-Entitäten verwerfen

Die mbstring-Funktionen (Multi-Byte-String) von PHP helfen uns bei der Arbeit mit Unicode, HTML-Entities und anderen Legacy-Textkodierungen.

Base64, Uuencode und QPrint sind jedoch keine Textcodierungen und sind immer noch Teil dieser Funktionen – hauptsächlich aus Legacy-Gründen. PHP enthält auch separate Implementierungen dieser Kodierungen.

Was HTML-Entities betrifft, so hat PHP eingebaute Funktionen – htmlspecialchars() und htmlentities() – um besser mit diesen umgehen zu können. Im Gegensatz zu mbstring konvertieren diese Funktionen beispielsweise auch < . > , und & Zeichen in HTML-Entitäten.

Darüber hinaus verbessert PHP ständig seine integrierten Funktionen – genau wie PHP 8.1 mit HTML-Codierungs- und -Decodierungsfunktionen.

Unter Berücksichtigung all dessen lehnt PHP 8.2 die Verwendung von mbstring für diese Kodierungen ab (bei den Labels wird die Groß-/Kleinschreibung nicht beachtet):

• BASIS64
• UUENCODE
• HTML-ENTITÄTEN
• html (Alias ​​von HTML-ENTITIES)
• Zitiert-Druckbar
• qprint (alias von Quoted-Printable)

Ab PHP 8.2 wird bei Verwendung von mbstring zum Codieren/Decodieren eines der oben genannten Elemente eine Verfallsmeldung ausgegeben. PHP 9.0 wird die mbstring-Unterstützung für diese Codierungen vollständig entfernen.

Andere kleinere Änderungen in PHP 8.2

Abschließend können wir die geringfügigen Änderungen von PHP 8.2 besprechen, einschließlich der entfernten Features und Funktionalitäten.

Entfernen Sie die Unterstützung für libmysql aus mysqli

Ab sofort erlaubt PHP sowohl mysqli als PDO_mysql Treibern, gegen mysqlnd und libmysql Bibliotheken zu bauen. Der standardmäßige und empfohlene Treiber seit PHP 5.4 ist jedoch mysqlnd .

Beide Treiber haben viele Vor- und Nachteile. Das Entfernen der Unterstützung für einen von ihnen – idealerweise das Entfernen von libmysql , da es nicht der Standard ist – vereinfacht jedoch den Code und die Unit-Tests von PHP.

Um diesen Gefallen zu argumentieren, listet der RFC viele Vorteile von mysqlnd :

• Es ist mit PHP gebündelt
• Es verwendet die PHP-Speicherverwaltung, um die Speichernutzung zu überwachen und
  Leistung verbessern
• Bietet Quality-of-Life-Funktionen (z. B. get_result() )
• Gibt numerische Werte mit nativen PHP-Typen zurück
• Seine Funktionalität hängt nicht von der externen Bibliothek ab
• Optionale Plugin-Funktionalität
• Unterstützt asynchrone Abfragen

Der RFC listet auch einige Vorteile von libmysql , darunter:

• Automatische Wiederverbindung ist möglich ( mysqlnd unterstützt diese Funktionalität nicht absichtlich, da sie leicht ausgenutzt werden kann)
• LDAP- und SASL-Authentifizierungsmodi ( mysqlnd fügt diese Funktion möglicherweise bald hinzu)

Darüber hinaus listet der RFC viele Nachteile von libmysql – Inkompatibilität mit dem PHP-Speichermodell, viele fehlgeschlagene Tests, Speicherlecks, unterschiedliche Funktionalitäten zwischen Versionen usw.

Vor diesem Hintergrund hat PHP 8.2 die Unterstützung für das Erstellen von mysqli gegen libmysql .

Wenn Sie Funktionen hinzufügen möchten, die nur mit libmysql verfügbar sind, müssen Sie sie explizit als Funktionsanforderung zu mysqlnd hinzufügen. Außerdem können Sie keine automatische Wiederverbindung hinzufügen.

Gebietsschema-unabhängige Groß-/Kleinschreibung

Vor PHP 8.0 wurde das Gebietsschema von PHP von der Systemumgebung geerbt. Dies könnte jedoch in einigen Randfällen zu Problemen führen.

Wenn Sie Ihre Sprache während der Installation von Linux einstellen, wird die entsprechende Sprache der Benutzeroberfläche für die integrierten Befehle eingestellt. Es ändert jedoch auch unerwarteterweise die Funktionsweise der String-Verarbeitungsfunktion der C-Bibliothek.

Wenn Sie beispielsweise bei der Installation von Linux die Sprache „Türkisch“ oder „Kasachisch“ ausgewählt haben, werden Sie feststellen, dass der Aufruf toupper('i') , um das Äquivalent in Großbuchstaben zu erhalten, das gepunktete große I (U+0130, I ) erhalten würde.

PHP 8.0 hat diese Anomalie gestoppt, indem es das Standardgebietsschema auf „C“ gesetzt hat, es sei denn, der Benutzer ändert es explizit über setlocale() .

PHP 8.2 geht sogar noch weiter, indem es die Gebietsschema-Sensitivität von der Groß-/Kleinschreibung entfernt. Dieser RFC ändert hauptsächlich strtolower() , strtoupper() und verwandte Funktionen. Lesen Sie den RFC für eine Liste aller betroffenen Funktionen.

Wenn Sie die lokalisierte Groß-/Kleinschreibung verwenden möchten, können Sie alternativ mb_strtolower() verwenden.

Verbesserung der zufälligen Erweiterung

PHP plant, seine Random-Funktionalität zu überarbeiten.

Ab sofort hängt die Zufallsfunktion von PHP stark vom Mersenne-Twister-Zustand ab. Dieser Zustand wird jedoch implizit im globalen Bereich von PHP gespeichert – ein Benutzer kann nicht darauf zugreifen. Das Hinzufügen von Randomisierungsfunktionen zwischen der anfänglichen Seeding-Phase und der beabsichtigten Verwendung würde den Code brechen.

Die Pflege eines solchen Codes kann noch komplizierter sein, wenn Ihr Code externe Pakete verwendet.

Daher kann die aktuelle Zufallsfunktion von PHP zufällige Werte nicht konsistent reproduzieren. Es scheitert sogar an empirischen statistischen Tests von einheitlichen Zufallszahlengeneratoren wie Crush und BigCrush von TestU01. Die 32-Bit-Beschränkung von Mersenne Twister verschärft dies noch.

Daher wird die Verwendung der in PHP integrierten Funktionen – shuffle() , str_shuffle() , array_rand() – nicht empfohlen, wenn Sie kryptografisch sichere Zufallszahlen benötigen. In solchen Fällen müssen Sie eine neue Funktion mit random_int() oder ähnlichen Funktionen implementieren.

Nach Beginn der Abstimmung wurden jedoch mehrere Probleme mit diesem RFC angesprochen. Dieser Rückschlag zwang das PHP-Team, alle Probleme in einem separaten RFC zu notieren, wobei für jedes Problem eine Abstimmungsoption erstellt wurde. Erst nach Erreichen eines Konsenses entscheiden sie über weitere Schritte.

Zusätzliche RFCs in PHP 8.2

PHP 8.2 enthält auch viele neue Funktionen und kleinere Änderungen. Wir erwähnen sie unten mit Links zu zusätzlichen Ressourcen:

1. Neue curl_upkeep -Funktion: PHP 8.2 fügt diese neue Funktion zu seiner Curl-Erweiterung hinzu. Es ruft die Funktion curl_easy_upkeep() in libcurl auf, der zugrunde liegenden C-Bibliothek, die die PHP-Curl-Erweiterung verwendet.
2. Neue ini_parse_quantity -Funktion: PHP-INI-Direktiven akzeptieren Datengrößen mit einem Multiplikator-Suffix. Beispielsweise können Sie 25 Megabyte als 25M oder 42 Gigabyte als nur 42G . Diese Suffixe sind in PHP-INI-Dateien üblich, aber anderswo ungewöhnlich. Diese neue Funktion analysiert die PHP-INI-Werte und gibt ihre Datengröße in Bytes zurück.
3. Neue Funktion memory_reset_peak_usage : Diese Funktion setzt die maximale Speicherauslastung zurück, die von der Funktion memory_get_peak_usage zurückgegeben wird. Dies kann praktisch sein, wenn Sie dieselbe Aktion mehrmals ausführen und die maximale Speicherauslastung jedes Laufs aufzeichnen möchten.
4. Unterstützung für No-Capture-Modifizierer ( /n ) in preg_* -Funktionen: In Regex geben die () -Metazeichen eine einfangende Gruppe an. Das bedeutet, dass alle Übereinstimmungen für den Ausdruck innerhalb der Klammer zurückgegeben werden. PHP 8.2 fügt einen No-Capture-Modifikator ( /n ) hinzu, um dieses Verhalten zu stoppen.
5. Lassen Sie die iterator_*() Familie alle Iterables akzeptieren: Ab sofort akzeptiert die iterator iterator_*() *()-Familie von PHP nur \Traversables (dh es sind keine einfachen Arrays erlaubt). Es schränkt unnötig ein, und dieser RFC behebt das.

Zusammenfassung

PHP 8.2 baut auf den massiven Verbesserungen in PHP 8.0 und PHP 8.1 auf, was keine leichte Aufgabe ist. Wir glauben, dass die aufregendsten Funktionen von PHP 8.2 die neuen eigenständigen Typen, schreibgeschützten Eigenschaften und zahlreiche Leistungsverbesserungen sind.

Wir können es kaum erwarten, PHP 8.2 mit verschiedenen PHP-Frameworks und CMS zu testen.

Stellen Sie sicher, dass Sie diesen Blog-Beitrag für zukünftige Referenzzwecke mit einem Lesezeichen versehen.

Welche Funktionen von PHP 8.2 sind Ihre Favoriten? Welche Abwertungen magst du am wenigsten? Bitte teilen Sie Ihre Gedanken mit unserer Community in den Kommentaren!