PHP 8 wird voraussichtlich im Dezember 2020 veröffentlicht und wird uns einen ganzen Haufen mächtiger Funktionen und großartige Sprachverbesserungen bringen.

Viele RFCs wurden bereits genehmigt und implementiert, also ist es Zeit für uns, in einige der aufregendsten Ergänzungen einzutauchen, die PHP schneller und zuverlässiger machen sollen.

Da PHP 8 noch in der Entwicklung ist, könnten wir vor der endgültigen Veröffentlichung noch einige Änderungen sehen. Wir werden diese Änderungen im Auge behalten und diesen Beitrag regelmäßig aktualisieren, also stellt sicher, dass ihr nichts über PHP 8 verpasst und schaut von Zeit zu Zeit noch einmal in diesem Beitrag nach.

Also, welche Funktionen und Verbesserungen sollten wir mit PHP 8 erwarten? Was ist das Größte, was mit PHP 8, der nächsten großen Version der Sprache, kommt?

Lasst uns loslegen!

PHP JIT (Just in Time Compiler)

Das am meisten gelobte Feature, das mit PHP 8 kommt, ist der Just-in-time (JIT) Compiler. Was hat es mit JIT auf sich?

Der RFC-Vorschlag beschreibt JIT wie folgt:

„PHP JIT ist als ein fast unabhängiger 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ätzlichen Region des OPcache-Shared Memory gespeichert und op_array→opcodes[].handler(s) behalten Zeiger auf die Einstiegspunkte des JIT-ed-Codes.“

Also, wie sind wir zu JIT gekommen und was ist der Unterschied zwischen JIT vs. OPcache?

Um besser zu verstehen, was JIT für PHP ist, wollen wir einen kurzen Blick darauf werfen, wie PHP vom Quellcode bis zum Endergebnis ausgeführt wird.

Die PHP-Ausführung ist ein 4-stufiger Prozess:

Das folgende Bild zeigt eine visuelle Darstellung des grundlegenden PHP-Ausführungsprozesses.

Grundlegender PHP-Ausführungsprozess

Grundlegender PHP-Ausführungsprozess

Also, wie macht OPcache PHP schneller? Und was ändert sich im Ausführungsprozess mit JIT?

Die OPcache-Erweiterung

PHP ist eine interpretierte Sprache. Das bedeutet, wenn ein PHP-Skript läuft, parst, kompiliert und führt der Interpreter den Code bei jeder Anfrage wieder und wieder aus. Dies kann zu einer Verschwendung von CPU-Ressourcen und zusätzlicher Zeit führen.

Hier kommt die OPcache-Erweiterung ins Spiel:

„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.“

Wenn OPcache aktiviert ist, durchläuft der PHP-Interpreter den oben erwähnten 4-Stufen-Prozess nur beim ersten Ausführen des Skripts. Da PHP-Bytekodes im Shared Memory gespeichert werden, sind sie sofort als low-level Zwischendarstellung verfügbar und können sofort auf der Zend VM ausgeführt werden.

PHP-Ausführungsprozess mit aktiviertem OPcache

PHP-Ausführungsprozess mit aktiviertem OPcache

Ab PHP 5.5 ist die Zend OPcache-Erweiterung standardmäßig verfügbar und du kannst überprüfen, ob du sie korrekt konfiguriert hast, indem du einfach phpinfo() von einem Skript auf deinem Server aufrufst oder deine php.ini-Datei auscheckst (siehe OPcache-Konfigurationseinstellungen).

Zend OPcache Sektion in einer phpinfo Seite

Zend OPcache Sektion in einer phpinfo Seite

Vorladen

OPcache wurde kürzlich mit der Implementierung des Vorladens verbessert, einer neuen OPcache-Funktion, die mit PHP 7.4 hinzugefügt wurde. Das Vorladen bietet dir eine Möglichkeit, einen bestimmten Satz von Skripten im OPcache-Speicher zu speichern, „bevor irgendein Anwendungscode ausgeführt wird“, aber es bringt keine greifbare Leistungsverbesserung für typische webbasierte Anwendungen.

Du kannst mehr über das Vorladen in unserer Einführung zu PHP 7.4 lesen.

Mit JIT geht PHP einen Schritt vorwärts.

JIT — The Just in Time Compiler

Auch wenn die Opcodes in Form von niedrigstufigen Zwischendarstellungen vorliegen, müssen sie dennoch in Maschinencode übersetzt werden. JIT „führt keine zusätzliche IR (Intermediate Representation)-Form ein“, sondern verwendet DynASM (Dynamic Assembler für Codegenerierungs-Engines), um nativen Code direkt aus dem PHP-Bytecode zu generieren.

Kurz gesagt, JIT übersetzt die heißen Teile des Zwischencodes in Maschinencode. Da es die Kompilierung umgeht, kann es erhebliche Verbesserungen der Leistung und des Speicherverbrauchs bringen.

Zeev Surasky, Co-Autor des PHP-JIT-Vorschlags, zeigt, um wie viel schneller Berechnungen mit JIT wären:

 

Aber, würde JIT die Leistung von WordPress effektiv verbessern?

JIT für Live Web Apps

Laut dem JIT RFC sollte die just in time Compiler Implementierung die PHP Performance verbessern. Aber würden wir solche Verbesserungen wirklich in echten Anwendungen wie WordPress erleben?

Die frühen Tests zeigen, dass JIT CPU-intensive Arbeitslasten deutlich schneller laufen lassen würde, warnt der RFC jedoch:

„… 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).

Es ist geplant, dir zusätzlichen Aufwand zu bieten, indem JIT für real-life Apps verbessert wird, mit Hilfe von Profiling und spekulativen Optimierungen“.

Mit aktiviertem JIT würde der Code nicht von der Zend VM, sondern von der CPU selbst ausgeführt werden, und das würde die Geschwindigkeit bei der Berechnung verbessern. Webanwendungen wie WordPress hängen auch von anderen Faktoren wie TTFB, Datenbankoptimierung, HTTP-Anfragen, etc. ab.

Also, wenn es um WordPress und ähnliche Anwendungen geht, sollten wir keine große Steigerung der PHP-Ausführungsgeschwindigkeit erwarten. Nichtsdestotrotz könnte JIT den Entwicklern einige Vorteile bringen.

Laut Nikita Popov:

„Die Vorteile des JIT-Compilers sind ungefähr (und wie bereits im RFC beschrieben):

  • Deutlich bessere Leistung für numerischen Code.
  • Etwas bessere Leistung für „typischen“ PHP-Webanwendungscode.
  • Das Potential, mehr Code von C nach PHP zu verschieben, da PHP nun ausreichend schnell sein wird.

Also, während JIT kaum riesige Verbesserungen der WordPress-Performance bringen wird, wird es PHP auf die nächste Stufe heben und es zu einer Sprache machen, in der viele Funktionen nun direkt geschrieben werden könnten.

Der Nachteil wäre allerdings die größere Komplexität, die zu steigenden Kosten für Wartung, Stabilität und Debugging führen kann. Laut Dmitry Stogov:

„JIT ist extrem einfach, aber trotzdem erhöht es den Grad der gesamten PHP-Komplexität, das Risiko neuartiger Bugs und die Kosten für Entwicklung und Wartung.

Der Vorschlag, JIT in PHP 8 aufzunehmen, wurde mit 50 zu 2 Stimmen angenommen.

PHP 8 kommt später in diesem Jahr. 🚀 Schaut euch unseren Einblick in die neuen Features an!Click to Tweet

PHP 8 Verbesserungen und neue Funktionen.

Abgesehen von JIT, können wir viele Funktionen und Verbesserungen mit PHP 8 erwarten. Die folgende Liste ist unsere handverlesene Auswahl der kommenden Ergänzungen und Änderungen, die PHP zuverlässiger und effizienter machen sollen.

Validierung für abstrakte Eigenschaftsmethoden

Eigenschaften 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önnen.

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.

Gemäß dem PHP-Handbuch,

„Eigenschaften unterstützen die Verwendung abstrakter Methoden, um Anforderungen an die ausstellende Klasse zu stellen.”

Das bedeutet auch, dass die Signaturen der Methoden übereinstimmen müssen. Mit anderen Worten, die Art und die Anzahl der benötigten Argumente müssen gleich sein.

Wie auch immer, laut Nikita Popov, Autor des RFC, wird die Signaturvalidierung derzeit nur punktuell durchgesetzt:

  • In den meisten Fällen wird sie nicht erzwungen, da die Methodenimplementierung von der verwendenden Klasse angeboten wird: https://3v4l.org/SeVK3
  • Es wird durchgesetzt, wenn die Implementierung von einer Parent-Klasse kommt: https://3v4l.org/4VCIp
  • Es wird durchgesetzt, wenn die Implementierung von einer Child-Klasse kommt: https://3v4l.org/q7Bq2

Das folgende Beispiel von Nikita bezieht sich auf den ersten Fall (nicht erzwungene Unterschrift):

trait T {
	abstract public function test(int $x);
}
 
class C {
	use T;

	// Allowed, but shouldn't be due to invalid type.
	public function test(string $x) {}
}

Davon abgesehen schlägt dieser RFC vor, immer einen fatalen Fehler zu werfen, wenn die Implementierungsmethode nicht mit der abstrakten Eigenschaftsmethode kompatibel ist, unabhängig von ihrem Ursprung:

Fatal error: Declaration of C::test(string $x) must be compatible with T::test(int $x) in /path/to/your/test.php on line 10

Dieser RFC wurde einstimmig angenommen.

Inkompatible Methodensignaturen

In PHP werfen Vererbungsfehler aufgrund inkompatibler Methodensignaturen entweder einen fatalen Fehler oder eine Warnung aus, je nachdem, was die Ursache des Fehlers ist.

Wenn eine Klasse ein Interface implementiert, führen inkompatible Methodensignaturen zu einem fatalen Fehler. Laut der Dokumentation zu Objekt Interfaces:

„Die Klasse, die das Interface implementiert, muss eine Methodensignatur verwenden, die mit dem LSP (Liskov Substitutionsprinzip) kompatibel ist. Wenn sie dies nicht tut, führt dies zu einem fatalen Fehler.“

Hier ist ein Beispiel für einen Vererbungsfehler mit einem Interface:

interface I {
	public function method(array $a);
}
class C implements I {
	public function method(int $a) {}
}

In PHP 7.4 würde der obige Code den folgenden Fehler auslösen:

Fatal error: Declaration of C::method(int $a) must be compatible with I::method(array $a) in /path/to/your/test.php on line 7

Eine Funktion in einer Child-Klasse mit einer inkompatiblen Signatur würde eine Warnung auslösen. Siehe den folgenden Code aus dem RFC:

class C1 {
	public function method(array $a) {}
}
class C2 extends C1 {
	public function method(int $a) {}
}

In PHP 7.4 würde der obige Code einfach eine Warnung ausgeben:

Warning: Declaration of C2::method(int $a) should be compatible with C1::method(array $a) in /path/to/your/test.php on line 7

Nun schlägt dieser RFC vor, bei inkompatiblen Methodensignaturen immer einen fatalen Fehler zu werfen. Mit PHP 8 würde der Code, den wir weiter oben gesehen haben, folgendes auslösen:

Fatal error: Declaration of C2::method(int $a) must be compatible with C1::method(array $a) in /path/to/your/test.php on line 7

Arrays, die mit einem negativen Index beginnen

In PHP, wenn ein Array mit einem negativen Index (start_index < 0) beginnt, beginnen die folgenden Indizes bei 0 (mehr dazu in der array_fill Dokumentation). Schau dir das folgende Beispiel an:

$a = array_fill(-5, 4, true);
var_dump($a);

In PHP 7.4 würde das Ergebnis wie folgt aussehen:

array(4) {
	[-5]=>
	bool(true)
	[0]=>
	bool(true)
	[1]=>
	bool(true)
	[2]=>
	bool(true)
}

Nun, dieser RFC schlägt vor, die Dinge so zu ändern, dass der zweite Index start_index + 1 wäre, was auch immer der Wert von start_index ist.

In PHP 8 würde der obige Code zu folgendem Array führen:

array(4) {
	[-5]=>
	bool(true)
	[-4]=>
	bool(true)
	[-3]=>
	bool(true)
	[-2]=>
	bool(true)
}

Mit PHP 8 ändern Arrays, die mit einem negativen Index beginnen, ihr Verhalten. Lies mehr über Rückwärtsinkompatibilitäten im RFC.

Union Types 2.0

Union types akzeptieren Werte, die von unterschiedlicher Art sein können. Derzeit bietet PHP keine Unterstützung für Union types, mit Ausnahme der ?Type syntax und dem special iterable type.

Vor PHP 8 konnten Union types nur in phpdoc-Annotationen angegeben werden, wie das folgende Beispiel aus dem RFC zeigt:

class Number {
	/**
	 * @var int|float $number
	 */
	private $number;

	/**
	 * @param int|float $number
	 */
	public function setNumber($number) {
		$this->number = $number;
	}

	/**
	 * @return int|float
	 */
	public function getNumber() {
		return $this->number;
	}
}

Nun schlägt der RFC für Union types 2.0 vor, Unterstützung für Union types in Funktionssignaturen hinzuzufügen, so dass wir uns nicht mehr auf die Inline-Dokumentation verlassen, sondern stattdessen Union types mit einer T1|T2|... Syntax definieren würden:

class Number {
	private int|float $number;

	public function setNumber(int|float $number): void {
		$this->number = $number;
	}

	public function getNumber(): int|float {
		return $this->number;
	}
}

Wie von Nikita Popov im RFC erklärt,

„Die Unterstützung von Union-Types in der Sprache erlaubt es uns, mehr Typinformationen aus phpdoc in Funktionssignaturen zu verschieben, mit den üblichen Vorteilen, die das mit sich bringt:

  • Typen werden tatsächlich durchgesetzt, so dass Fehler frühzeitig erkannt werden können.
  • Weil sie erzwungen werden, ist die Wahrscheinlichkeit geringer, dass Typinformationen veraltet sind oder Randfehler übersehen werden.
  • Die Typen werden während der Vererbung überprüft, wodurch das Liskov-Substitutionsprinzip durchgesetzt wird.
  • Die Typen sind über Reflection verfügbar.
  • Die Syntax ist viel weniger Boilerplate-y als phpdoc“.

Union types unterstützen alle verfügbaren Typen, mit einigen Einschränkungen:

  • Der Typ void kann nicht Teil einer Union sein, da void bedeutet, dass eine Funktion keinen Wert zurückgibt.
  • Der null-Typ wird nur in Union types unterstützt, aber seine Verwendung als eigenständiger Typ ist nicht erlaubt.
  • Die nullbare Typ-Notation (?T) ist auch erlaubt, was T|null bedeutet, aber wir dürfen die ?T-Notation nicht in Union types verwenden (?T1|T2 ist nicht erlaubt und wir sollten stattdessen T1|T2|null verwenden).
  • Da viele Funktionen (z.B. strpos(), strstr(), substr(), etc.) false unter den möglichen Rückgabetypen einschließen, wird auch der false Pseudo-Typ unterstützt.

Mehr über Union Types V2 könnt ihr im RFC nachlesen.

Konsistente Typ-Fehler für interne Funktionen

Wenn ein Parameter vom illegalen Typ übergeben wird, verhalten sich interne und benutzerdefinierte Funktionen unterschiedlich.

Benutzerdefinierte Funktionen werfen einen TypeError, aber interne Funktionen verhalten sich unterschiedlich, abhängig von verschiedenen Bedingungen. Wie auch immer, das typische Verhalten ist, eine Warnung zu werfen und null zurückzugeben. Siehe das folgende Beispiel in PHP 7.4:

var_dump(strlen(new stdClass));

Dies würde zu folgender Warnung führen:

Warning: strlen() expects parameter 1 to be string, object given in /path/to/your/test.php on line 4
NULL

Wenn strict_types aktiviert ist, oder argument information Typen angibt, wäre das Verhalten anders. In solchen Szenarien wird der Typfehler erkannt und führt zu einem TypeError.

Diese Situation würde zu einer Reihe von Problemen führen, die in der Issues-Sektion des RFC gut erklärt sind.

Um diese Inkonsistenzen zu beseitigen, schlägt dieser RFC vor, die internen Parameter-Parsing-APIs so zu gestalten, dass sie immer einen ThrowError erzeugen, wenn ein Parametertyp nicht übereinstimmt.

In PHP 8 wirft der obige Code den folgenden Fehler aus:

Fatal error: Uncaught TypeError: strlen(): Argument #1 ($str) must be of type string, object given in /path/to/your/test.php:4
Stack trace:
#0 {main}
  thrown in /path/to/your/test.php on line 4

throw Expression

In PHP ist throw eine Anweisung, daher ist es nicht möglich, sie an Stellen zu verwenden, an denen nur ein Ausdruck erlaubt ist.

Dieser RFC schlägt vor, die throw-Anweisung in einen Ausdruck umzuwandeln, so dass sie in jedem Kontext verwendet werden kann, wo Ausdrücke erlaubt sind. Zum Beispiel arrow Funktionen, Null-Koaleszenz-Operator, ternäre und Elvis-Operatoren, etc.

Siehe die folgenden Beispiele aus dem RFC:

$callable = fn() => throw new Exception();

// $value is non-nullable.
$value = $nullableValue ?? throw new InvalidArgumentException();
 
// $value is truthy.
$value = $falsableValue ?: throw new InvalidArgumentException();

Weak Maps

Eine Weak Map ist eine Sammlung von Daten (Objekten), in der Schlüssel schwach referenziert werden, was bedeutet, dass sie nicht daran gehindert werden, Müll zu sammeln.

PHP 7.4 fügte Unterstützung für schwache Referenzen hinzu, um einen Verweis auf ein Objekt zu erhalten, was nicht verhindert, dass das Objekt selbst zerstört wird. Wie von Nikita Popov angemerkt,

„Rohe schwache Verweise sind für sich genommen nur von begrenztem Nutzen und Weak Maps werden in der Praxis viel häufiger verwendet. Es ist nicht möglich, eine effiziente Weak Map zusätzlich zu den PHP-Schwachen Referenzen zu implementieren, da die Möglichkeit, einen Zerstörungs-Callback zu registrieren, nicht angeboten wird.“

Aus diesem Grund führt dieser RFC eine WeakMap-Klasse ein, um Objekte zu erstellen, die als Weak Map-Schlüssel verwendet werden, die zerstört und von der Weak Map entfernt werden können, wenn es keine weiteren Referenzen auf das Schlüsselobjekt gibt.

In lang laufenden Prozessen würde dies Speicherlecks verhindern und die Performance verbessern. Siehe das folgende Beispiel aus dem RFC:

$map = new WeakMap;
$obj = new stdClass;
$map[$obj] = 42;
var_dump($map);

Mit PHP 8 würde der obige Code das folgende Ergebnis erzeugen (siehe den Code in Aktion hier):

object(WeakMap)#1 (1) {
	[0]=>
	array(2) {
		["key"]=>
		object(stdClass)#2 (0) {
		}
		["value"]=>
		int(42)
	}
}

Wenn du das Objekt entsperrst, wird der Schlüssel automatisch von der Weak Map entfernt:

unset($obj);
var_dump($map);

Nun wäre das Ergebnis wie folgt:

object(WeakMap)#1 (0) {
}

Für eine genauere Betrachtung der Weak Maps siehe RFC. Der Vorschlag wurde einstimmig angenommen.

Du brauchst ein blitzschnelles, sicheres und entwicklerfreundliches Hosting für deine Webseiten? Kinsta wurde mit Blick auf WordPress-Entwickler entwickelt und bietet dir zahlreiche Tools und ein leistungsstarkes Dashboard. Schaut euch unsere Pläne an

Nachkomma in Parameterliste

Nachkommas sind Kommas, die an Listen von Elementen in verschiedenen Kontexten angehängt werden. PHP 7.2 führte die Anhängung von Kommas in der Listensyntax ein, PHP 7.3 führte die Anhängung von Kommas in Funktionsaufrufen ein.

PHP 8 führt in Parameterlisten mit Funktionen, Methoden und Abschlüssen nun auch Nachkommas in Parameterlisten ein, wie das folgende Beispiel zeigt:

class Foo {
	public function __construct(
		string $x,
		int $y,
		float $z, // trailing comma
	) {
		// do something
	}
}

Dieser Antrag wurde mit 58 zu 1 Stimmen angenommen.

Allow ::class syntax on objects

Um den Namen einer Klasse abzurufen, können wir die Syntax Foo\Bar::class verwenden. Dieser RFC schlägt vor, die gleiche Syntax auf Objekte auszudehnen, so dass es nun möglich ist, den Namen der Klasse eines gegebenen Objekts zu holen, wie im folgenden Beispiel gezeigt:

$object = new stdClass;
var_dump($object::class); // "stdClass"
 
$object = null;
var_dump($object::class); // TypeError

Mit PHP 8 bietet $object::class das gleiche Ergebnis wie get_class($object). Wenn $object kein Objekt ist, wirft es eine TypeError-Ausnahme aus.

Dieser Vorschlag wurde einstimmig angenommen.

Attributes v2

Attribute, auch als Annotationen bekannt, sind eine Form strukturierter Metadaten, die zur Angabe von Eigenschaften für Objekte, Elemente oder Dateien verwendet werden können.

Bis PHP 7.4 waren Doc-Kommentare die einzige Möglichkeit, Metadaten zu Deklarationen von Klassen, Funktionen usw. hinzuzufügen. Jetzt führt der RFC Attributes v2 Attribute für PHP ein und definiert sie als eine Form von strukturierten, syntaktischen Metadaten, die zu Deklarationen von Klassen, Eigenschaften, Funktionen, Methoden, Parametern und Konstanten hinzugefügt werden können.

Attribute werden vor den Deklarationen, auf die sie sich beziehen, hinzugefügt. Siehe die folgenden Beispiele aus dem RFC:

<>
class Foo
{
	<>
	public const FOO = 'foo';

	<>
	public $x;

	<>
	public function foo(<> $bar) { }
}

$object = new <> class () { };

<>
function f1() { }

$f2 = <> function () { };

$f3 = <> fn () => 1;

Attribute können vor oder nach einem Dok-Block-Kommentar hinzugefügt werden:

<>
/** docblock */
<>
function foo() {}

Jede Deklaration kann ein oder mehrere Attribute haben, und jedes Attribut kann einen oder mehrere zugehörige Werte haben:

<>
<<SingleArgument(0)>>
<<FewArguments('Hello', 'World')>>
function foo() {}

Einen tieferen Überblick über PHP-Attribute, Anwendungsfälle und alternative Syntax findest du im RFC.

Neue PHP-Funktionen

PHP 8 bringt mehrere neue Funktionen in die Sprache:

str_contains

Vor PHP 8 waren strstr und strpos die typischen Optionen für Entwickler, um nach einer Nadel innerhalb einer gegebenen Zeichenkette zu suchen. Das Problem ist, dass beide Funktionen nicht als sehr intuitiv angesehen werden und ihre Verwendung für neue PHP-Entwickler verwirrend sein kann. Siehe das folgende Beispiel:

$mystring = 'Managed WordPress Hosting';
$findme = 'WordPress';
$pos = strpos($mystring, $findme);

if ($pos !== false) {
	echo "The string has been found";
} else {
	echo "String not found";
}

Im obigen Beispiel haben wir den Vergleichsoperator !== verwendet, der auch prüft, ob zwei Werte vom gleichen Typ sind. Dies verhindert, dass wir einen Fehler erhalten, wenn die Position der Nadel 0 ist:

„Diese Funktion kann den booleschen FALSE zurückgeben, kann aber auch einen nicht-booleschen Wert zurückgeben, der als FALSE gewertet wird. […] Verwende den Operator ===, um den Rückgabewert dieser Funktion zu testen.“

Darüber hinaus bieten dir mehrere Frameworks Hilfsfunktionen an, um nach einem Wert innerhalb einer gegebenen Zeichenfolge zu suchen (siehe Laravel-Helfer-Dokumentation als Beispiel).

Nun schlägt dieser RFC die Einführung einer neuen Funktion vor, die es erlaubt, innerhalb einer Zeichenkette zu suchen: str_contains.

str_contains ( string $haystack , string $needle ) : bool

Seine Verwendung ist ziemlich einfach. str_contains prüft, ob $needle in $haystack gefunden wird und gibt entsprechend true oder false zurück.

Dank str_contains können wir also den folgenden Code schreiben:

$mystring = 'Managed WordPress Hosting';
$findme   = 'WordPress';

if (str_contains($mystring, $findme)) {
	echo "The string has been found";
} else {
	echo "String not found";
}

Der besser lesbar und weniger fehleranfällig ist (siehe diesen Code in Aktion hier).

Zum Zeitpunkt des Verfassens dieses Artikels unterscheidet str_contains zwischen Groß- und Kleinschreibung, aber das könnte sich in Zukunft ändern.

Der Vorschlag str_contains wurde mit 43 zu 9 Stimmen angenommen.

str_starts_with() und str_ends_with()

Zusätzlich zur Funktion str_contains ermöglichen zwei neue Funktionen die Suche nach einer Nadel innerhalb einer gegebenen Zeichenfolge: str_starts_with und str_ends_with.

Diese neuen Funktionen prüfen, ob eine gegebene Zeichenkette mit einer anderen Zeichenkette beginnt oder endet:

str_starts_with (string $haystack , string $needle) : bool
str_ends_with (string $haystack , string $needle) : bool

Beide Funktionen geben false zurück, wenn $needle länger als $haystack ist.

Laut Will Hudgins, dem Autor dieses RFC,

„Die Funktionalität str_starts_with und str_ends_with wird so häufig benötigt, dass viele wichtige PHP-Frameworks sie unterstützen, darunter Symfony, Laravel, Yii, FuelPHP und Phalcon.“

Dank ihnen konnten wir nun die Verwendung suboptimaler und weniger intuitiver Funktionen wie substr, strpos vermeiden. Bei beiden Funktionen wird zwischen Groß- und Kleinschreibung unterschieden:

$str = "WordPress";
if (str_starts_with($str, "Word")) echo "Found!";

if (str_starts_with($str, "word")) echo "Not found!";

Du kannst diesen Code hier in Aktion sehen.

Dieser RFC wurde mit 51 zu 4 Stimmen genehmigt.

get_debug_type

get_debug_type ist eine neue PHP-Funktion, die den Typ einer Variablen zurückgibt. Die neue Funktion funktioniert ziemlich ähnlich wie die gettype-Funktion, aber get_debug_type liefert native Typnamen zurück und löst Klassennamen auf.

Das ist eine gute Verbesserung für die Sprache, da gettype() für die Typüberprüfung nicht nützlich ist.

Der RFC bietet dir zwei nützliche Beispiele, um den Unterschied zwischen der neuen get_debug_type()-Funktion und gettype() besser zu verstehen. Das erste Beispiel zeigt gettype bei der Arbeit:

$bar = [1,2,3];

if (!($bar instanceof Foo)) { 
	throw new TypeError('Expected ' . Foo::class . ', got ' . (is_object($bar) ? get_class($bar) : gettype($bar)));
}

Mit PHP 8 könnten wir stattdessen get_debug_type verwenden:

if (!($bar instanceof Foo)) { 
	throw new TypeError('Expected ' . Foo::class . ' got ' . get_debug_type($bar));
}

Die folgende Tabelle zeigt die Rückgabewerte von get_debug_type und gettype:

Value gettype() get_debug_type()
1 integer int
0.1 double float
true boolean bool
false boolean bool
null NULL null
„WordPress“ string string
[1,2,3] array array
A class with name „Foo\Bar“ object Foo\Bar
An anonymous class object class@anonymous

Zusätzliche RFCs

Zum Zeitpunkt des Schreibens dieses Artikels befinden sich mehrere RFCs, die auf PHP 8 abzielen, noch im Entwurf und/oder in der Implementierung. Wir werden sie hinzufügen, sobald sich ihr Status auf „Implementiert“ ändert.

Hier ist eine kurze Liste von zusätzlichen genehmigten Verbesserungen, die Teil von PHP 8 sein werden:

  1. Stringable Interface: Dieser RFC führt ein Stringable Interface ein, das automatisch zu Klassen hinzugefügt wird, die die __to String()-Methode implementieren. Das Hauptziel hier ist die Verwendung des Union-Typs string|Stringable.
  2. Neue DOM-Lebensstandard-APIs in ext/dom: dieser RFC schlägt vor, den aktuellen DOM-Lebensstandard in die PHP-DOM-Erweiterung zu implementieren, indem neue Interfaces und öffentliche Eigenschaften eingeführt werden.
  3. Statischer Rückgabetyp: PHP 8 führt die Verwendung von static als Rückgabetyp neben self und parent Typen ein.
  4. Variable Syntax Tweaks: dieser RFC löst einige verbleibende Inkonsistenzen in der Variablensyntax von PHP auf.
PHP 8 kommt später in diesem Jahr und wird viele Änderungen und Verbesserungen bringen. 🚀 Schaut euch unseren tiefen Einblick in die neuen Funktionen an!Click to Tweet

Zusammenfassung

Was für eine Reise! In diesem Beitrag haben wir alle wichtigen Änderungen und Verbesserungen behandelt, die mit der Veröffentlichung von PHP 8 erwartet werden. Die am meisten erwartete davon ist sicherlich der Just in Time Compiler, aber mit PHP 8 kommt noch so viel mehr.

Setzt euch auf jeden Fall ein Lesezeichen für diesen Blogeintrag, denn wir werden unsere Favoriten zur Liste hinzufügen, sobald sie genehmigt sind. 🤓

Jetzt bist du dran: Bist du bereit, die kommenden PHP-Features zu testen? Welches ist dein Lieblingsfeature? Schreibe eine Zeile in den Kommentarbereich unten.


Wenn Dir dieser Artikel gefallen hat, dann wirst du Kinsta’s WordPress Hosting-Plattform lieben. Beschleunige deine Webseite und erhalte 24/7 Support von unserem erfahrenen WordPress-Team. Unsere Google Cloud basierte Infrastruktur konzentriert sich auf die Bereiche Auto-Scaling, Performance und Sicherheit. Lass uns dir den Kinsta-Unterschied zeigen! Schau Dir hier unsere Pakete an