PHP 8.2 bouwt voort op de vernieuwde basis van PHP 8.0 en PHP 8.1. Nu PHP 8.2 is uitgebracht zullen we in detail bespreken wat er nieuw is in PHP 8.2 – van de nieuwe features en verbeteringen tot deprecaties en kleine wijzigingen, we zullen ze allemaal doornemen.

Omdat PHP 8.2 op 19 juli 2022 zijn feature freeze inging, kun je geen belangrijke toevoegingen aan deze lijst verwachten.

Enthousiast? Wij ook!

Laten we beginnen!

Nieuwe functies en verbeteringen in PHP 8.2

Laten we beginnen met het verkennen van alle nieuwste functies van PHP 8.2. En dit is nogal een uitgebreide lijst:

Nieuwe readonly classes

PHP 8.1 introduceerde de functiereadonly voor properties van classes. Nu voegt PHP 8.2 ondersteuning toe om de hele class te declareren als readonly.

Als je een class declaret als readonly, inheriten alle properties automatisch de property readonly. Het declareren van een class readonly is dus hetzelfde als het declareren van alle class-properties als readonly.

Met PHP 8.1 moest je bijvoorbeeld deze lastige code schrijven om alle class-properties te declareren als readonly:

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

Stel je hetzelfde voor met nog veel meer properties. Met PHP 8.2 kun je gewoon dit schrijven:

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

Je kunt ook abstracte of definitieve classes declareren als readonly. Hierbij maakt de volgorde van de woorden niet uit.

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

Je kunt ook een readonly class declareren zonder properties. Dit voorkomt in feite dynamische properties, terwijl childclasses toch hun readonly properties expliciet kunnen declareren.

Vervolgens kunnen readonly classes alleen typed properties bevatten – dezelfde regel voor het declareren van individuele readonly properties.

Je kunt de mixed type property gebruiken als je geen strikt typed property kunt declareren.

Proberen een readonly class te declareren zonder een typed property levert een Fatal error op:

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

Verder kun je readonly niet declareren voor bepaalde PHP-properties:

Pogingen om een van deze functies te declareren als readonly leiden tot een Parse error.

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

Zoals voor alle PHP keywords geldt, is ook het keyword readonly hoofdletterongevoelig.

PHP 8.2 schrijft verder dynamische properties af (daarover later meer). Maar je kunt niet voorkomen dat dynamische properties aan een class worden toegevoegd. Als je dat echter doet voor een class readonly, levert dat alleen een Fatal Error op.

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

true, false, en null toegestaan als zelfstandige types

PHP kent al scalaire types als int, string, en bool. Dat werd uitgebreid in PHP 8.0 met de toevoeging van union types, waardoor waarden van verschillende types kunnen zijn. Dezelfde RFC stond ook het gebruik toe van false en null als onderdeel van een union type – maar niet als zelfstandige types.

Als je probeerde false of null of als zelfstandige types te declareren – zonder dat ze deel uitmaakten van een union type – leverde dat een fatal error op.

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

Om dit scenario te vermijden voegt PHP 8.2 ondersteuning toe voor het gebruik van false en null als zelfstandige types. Met deze toevoeging is het typesysteem van PHP expressiever en completer. Je kunt nu de return, parameter en property types nauwkeurig declareren.

Ook bevat PHP nog steeds geen true type, dat een natuurlijke tegenhanger lijkt te zijn van het false type. PHP 8.2 lost dat op en voegt ook ondersteuning toe voor het type true. Het staat geen coërcie toe, precies zoals het type false zich gedraagt.

Zowel de true als de false types zijn in wezen een union type van PHP’s bool type. Om redundantie te voorkomen, kun je deze drie types niet samen declareren in een union type. Doe je dat wel, dan krijg je een fatale compileerfout.

Disjunctive Normal Form (DNF) types

Disjunctive Normal Form (DNF) is een gestandaardiseerde manier om boolean expressions te organiseren. Het bestaat uit een disjunctie van conjunctions – in booleaanse termen is dat een OR van AND’s.

Door DNF toe te passen op type-declaraties ontstaat een standaard manier om gecombineerde Union en Intersection types te schrijven die de parser kan verwerken. PHP 8.2’s nieuwe functie DNF types is eenvoudig maar krachtig, mits goed gebruikt.

De RFC geeft het volgende voorbeeld. Het gaat ervan uit dat de volgende interface en class definities al bestaan:

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 {}

Met DNF types kun je type-declaraties voor properties, parameters en returrn values als volgt uitvoeren:

// 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 sommige gevallen zijn de properties niet in DNF-vormen. Ze als zodanig declareren levert een parsefout op. Maar je kunt ze altijd herschrijven 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

Let op dat elk segment van een DNF type uniek moet zijn. Zo is het declareren van (A&B)|(B&A) ongeldig, omdat de twee ge-OR-ede segmenten logisch gezien hetzelfde zijn.

Bovendien zijn segmenten die strikte subsegmenten zijn van het andere segment ook niet toegestaan. Dat komt omdat de superset al alle instanties van de subset bevat, waardoor het gebruik van DNF overbodig wordt.

Sensitive parameters in back traces bewerken

Zoals bijna elke programmeertaal maakt PHP het mogelijk om de callstack op elk punt in de uitvoering van de code te traceren. Stack tracing maakt het gemakkelijk om code te debuggen om fouten en prestatieproblemen op te lossen. Het vormt de ruggengraat van tools zoals Kinsta APM, onze op maat ontworpen tool voor prestatiemonitoring van WordPress sites.

Traceren van trage WooCommerce transacties met Kinsta APM.
Traceren van trage WooCommerce transacties met Kinsta APM.

Het uitvoeren van een stack trace stopt de uitvoering van het programma niet. Gewoonlijk worden de meeste stack traces op de achtergrond uitgevoerd en stilletjes gelogd – voor latere inspectie indien nodig.

Sommige van deze gedetailleerde PHP stack traces kunnen echter een nadeel zijn als je ze deelt met externe diensten – meestal voor analyse van foutenlogs, foutopsporing, enz. Deze stack traces kunnen gevoelige informatie bevatten, zoals gebruikersnamen, wachtwoorden en omgevingsvariabelen.

Dit RFC voorstel geeft zo’n voorbeeld:

Een veel voorkomende “overtreder” is PDO die het databasewachtwoord als constructor parameter ziet en onmiddellijk binnen de constructor probeert te verbinden met de database, in plaats van een pure constructor en een aparte ->connect() methode. Als de databaseverbinding mislukt, bevat de stack trace dus het databasewachtwoord:

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}

Met PHP 8.2 kun je zulke gevoelige parameters markeren met een nieuw SensitiveParameter attribuut. Elke sensivite gemarkeerde parameter wordt niet vermeld in je back traces. Je kunt ze dus zonder zorgen delen met externe diensten.

Hier is een eenvoudig voorbeeld met een enkele sensivite 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
*/

Wanneer je een backt race genereert, wordt elke parameter met het SensitiveParameter attribuut vervangen door een SensitiveParameterValue object, en de echte waarde ervan wordt nooit opgeslagen in de trace. Het SensitiveParameterValue object kapselt de werkelijke parameterwaarde in – als je die om welke reden dan ook nodig hebt.

Nieuwe mysqli_execute_query functie en mysqli::execute_query methode

Heb je ooit de mysqli_query() functie gebruikt met gevaarlijk ontsnappende gebruikerswaarden om een MySQLi query met parameters uit te voeren?

PHP 8.2 maakt het uitvoeren van geparametriseerde MySQLi queries eenvoudiger met de nieuwe mysqli_execute_query($sql, $params) functie en mysqli::execute_query methode.

In wezen is deze nieuwe functie een combinatie van de functies mysqli_prepare(), mysqli_execute() en mysqli_stmt_get_result(). Hiermee wordt de MySQLi query voorbereid, gebonden (als je parameters doorgeeft), en uitgevoerd binnen de functie zelf. Als de query succesvol wordt uitgevoerd, geeft hij een mysqli_result object terug. Als hij niet succesvol is, geeft hij false terug.

Het RFC voorstel geeft een eenvoudig maar krachtig voorbeeld:

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

enum properties fetchen in const expressions

Deze RFC stelt voor om de ->/?-> operator toe te staan om enum properties in const expressions te fetchen.

De belangrijkste reden voor deze nieuwe functie is dat je enum objecten op sommige plaatsen niet kunt gebruiken, zoals array-keys. In zo’n geval moet je de waarde van de enum case herhalen om het te kunnen gebruiken.

Het toestaan van het fetchen van enum properties op plaatsen waar enum objecten niet zijn toegestaan, kan deze procedure vereenvoudigen.

Het betekent dat de volgende code nu geldig is:

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

En voor de zekerheid bevat deze RFC ook ondersteuning voor de nullsafe operator ?->.

Constanten toestaan in Traits

PHP bevat een manier om code te hergebruiken, genaamd Traits. Ze zijn geweldig voor hergebruik van code in verschillende classes.

Momenteel kun je met Traits alleen methoden en properties definiëren, maar geen constanten. Dat betekent dat je invarianten die door een Trait worden verwacht niet in de Trait zelf kunt definiëren. Om deze beperking te omzeilen, moet je constanten definiëren in de composing class of in een interface die door de composing class wordt geïmplementeerd.

Deze RFC stelt voor om het definiëren van constanten in Traits toe te staan. Deze constanten kunnen worden gedefinieerd zoals je classconstanten zou definiëren. Dit voorbeeld uit de RFC verduidelijkt het gebruik ervan:

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';
        }
    }
}

Trait-constanten worden ook samengevoegd in de definitie van de composing class, net als de definities van properties en methoden van een Trait. Ze hebben ook dezelfde beperkingen als properties van Traits. Zoals opgemerkt in de RFC, moet dit voorstel – hoewel een goed begin – verder worden uitgewerkt.

Afschrijvingen in PHP 8.2

Nu is het tijd om naar alle afschrijvingen in PHP 8.2 te kijken. Deze lijst is (gelukkig) niet zo groot als de nieuwe features:

Afschrijving van dynamische properties (en nieuw attribuut #[AllowDynamicProperties])

Tot PHP 8.1 kon je in PHP dynamisch niet gedeclareerde class-properties instellen en opvragen. Bijvoorbeeld:

class Post {
    private int $pid;
}

$post = new Post();
$post->name = 'Kinsta';

Hier declaret de class Post geen property name. Maar omdat PHP dynamische properties toestaat, kun je die instellen buiten de class-declaratie om. Dat is het grootste – en mogelijk enige – voordeel.

Dynamische properties zorgen voor onverwachte bugs en gedrag in je code. Als je bijvoorbeeld een fout maakt bij het declareren van een class-property buiten de class, kun je die gemakkelijk uit het oog verliezen – vooral bij het debuggen van fouten binnen die class.

Vanaf PHP 8.2 zijn dynamische properties afgeschreven. Het instellen van een waarde op een niet gedeclareerde class-property zal de eerste keer dat de property wordt ingesteld een afschrijvingsmelding geven.

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;

Echter, vanaf PHP 9.0 zal het instellen ervan een ErrorException foutmelding geven.

Als je code vol zit met dynamische properties – en dat is veel PHP code – en als je deze depreciatiemeldingen wilt stoppen na een upgrade naar PHP 8.2, kun je het nieuwe attribuut #[AllowDynamicProperties] van PHP 8.2 gebruiken om dynamische properties bij classes toe te staan.

#[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;

Volgens de RFC kunnen classes die gemarkeerd zijn als #[AllowDynamicProperties], evenals hun childclasses, dynamische properties blijven gebruiken zonder afschrijving of verwijdering.

Je moet ook weten dat in PHP 8.2 de enige gebundelde class die gemarkeerd is als #[AllowDynamicProperties] de stdClass is. Verder worden properties die benaderd worden via __get() of __set() PHP magische methoden niet beschouwd als dynamische properties, zodat ze geen depreciatiemelding krijgen.

Gedeeltelijk ondersteunde callables afschrijven

Een andere wijziging in PHP 8.2, zij het met een meer verwaarloosbaar effect, is het afschrijven van gedeeltelijk ondersteunde callables.

Deze callables worden gedeeltelijk ondersteund genoemd omdat je ze niet direct kunt gebruiken via $callable(). Je kunt ze alleen bereiken met de functie call_user_func($callable). De lijst van zulke callables is niet lang:

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

Vanaf PHP 8.2 zal elke poging om zulke callables aan te roepen – zoals via call_user_func() of array_map() functies – een deprecatiewaarschuwing geven.

De oorspronkelijke RFC geeft een goede reden voor deze deprecatie:

Afgezien van de laatste twee gevallen zijn al deze callables contextafhankelijk. Naar welke methode "self::method" verwijst hangt af van de class van waaruit de call of de controle van de callabiliteit wordt uitgevoerd. In de praktijk geldt dit meestal ook voor de laatste twee gevallen, bij gebruik in de vorm van [new Foo, "parent::method"].

Het verminderen van de context-dependency van callables is het secundaire doel van deze RFC. Na deze RFC is de enige overgebleven scope-dependency de zichtbaarheid van methoden: "Foo::bar" kan zichtbaar zijn in de ene scope, maar niet in een andere. Als callables in de toekomst beperkt zouden worden tot publieke methoden (terwijl private methoden eersteklas callables of Closure::fromCallable() zouden moeten gebruiken om scope-onafhankelijk te worden), dan zou het type callable goed gedefinieerd worden en gebruikt kunnen worden als een propertystype. Veranderingen in de handling van zichtbaarheid worden echter niet voorgesteld als onderdeel van deze RFC.

Volgens de oorspronkelijke RFC zullen de is_callable() functie en het callable type deze callables blijven accepteren als uitzonderingen. Maar alleen totdat de ondersteuning ervoor vanaf PHP 9.0 geheel wordt verwijderd.

Om verwarring te voorkomen is de reikwijdte van deze deprecation notice uitgebreid met een nieuwe RFC – het bevat nu ook deze exceptions.

Het is goed om te zien dat PHP evolueert naar een goed gedefinieerd callable type.

Afschrijving #utf8_encode() en utf8_decode() functies

PHP’s ingebouwde functies utf8_encode() en utf8_decode() converteren strings gecodeerd in ISO-8859-1 (“Latin 1”) naar en van UTF-8.

Hun namen suggereren echter een algemener gebruik dan hun implementatie toelaat. De “Latin 1” codering wordt vaak verward met andere coderingen zoals de “Windows Code Page 1252”

Verder zie je meestal Mojibake als deze functies een string niet goed kunnen converteren. Het ontbreken van foutmeldingen betekent ook dat het moeilijk is ze te herkennen, vooral in een zee van anders leesbare tekst.

PHP 8.2 deprecieert de functies #utf8_encode() en utf8_decode() af. Als je ze callt, zie je deze deprecatiemeldingen:

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

De RFC stelt voor om in plaats daarvan PHP’s ondersteunde extensies als mbstring, iconv, en intl te gebruiken.

Afschrijven${} string-interpolatie

PHP staat het inbedden van variabelen in strings met dubbele aanhalingstekens (") en heredoc (<<<) op verschillende manieren toe:

  1. Variabelen direct insluiten – Met accolades “$foo”
  2. Met accolades buiten de variabele – “{$foo}”
  3. Met accolades na het dollarteken – Met accolades na het dollarteken “${foo}”
  4. Variabele variabelen – “${expr}” – equivalent aan het gebruik van (string) ${expr}

De eerste twee manieren hebben hun voor- en nadelen, terwijl de laatste twee een complexe en tegenstrijdige syntaxis hebben. PHP 8.2 schrijft de laatste twee manieren van string-interpolatie af.

Je kunt voortaan geen strings meer op deze manier interpoleren:

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

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

Vanaf PHP 9.0 krijg je bij het gebruik hiervan in plaats daarvan een exception error.

Afschrijving mbstring functies voor Base64/QPrint/Uuencode/HTML entiteiten

PHP’s mbstring (multi-byte string) functies helpen ons te werken met Unicode, HTML entiteiten en andere oude tekstcoderingen.

Base64, Uuencode en QPrint zijn echter geen tekstcoderingen en zijn nog steeds onderdeel van deze functies – voornamelijk om te zorgen dat oudere system ook nog functioneren. PHP bevat daarnaast aparte implementaties van deze coderingen.

Voor HTML-entiteiten heeft PHP ingebouwde functies – htmlspecialchars() en htmlentities() – om daar beter mee om te gaan. In tegenstelling tot mbstring zullen deze functies bijvoorbeeld ook <. >, en & karakters om naar HTML entiteiten.

Bovendien verbetert PHP steeds zijn ingebouwde functies – net als PHP 8.1 met HTML coderings- en decoderingsfuncties.

Dus, met dat alles in gedachten, schrijft PHP 8.2 het gebruik van mbstring voor deze coderingen af (de labels zijn hoofdletter-ongevoelig):

  • BASE64
  • UUENCODE
  • HTML-ENTITIES
  • html (alias van HTML-ENTITIES)
  • Geciteerd-afdrukbaar
  • qprint (alias van Quoted-Printable)

Vanaf PHP 8.2 zal het gebruik van mbstring voor het coderen/decoderen van het bovenstaande een deprecatiemelding geven. PHP 9.0 zal de mbstring ondersteuning voor deze coderingen helemaal verwijderen.

Andere kleine veranderingen in PHP 8.2

Tenslotte kunnen we de kleine veranderingen van PHP 8.2 bespreken, waaronder de verwijderde properties en functies.

Ondersteuning voor libmysql uit mysqli verwijderd

Vanaf nu staat PHP zowel mysqli als PDO_mysql drivers toe om te bouwen tegen mysqlnd en libmysql libraries. Het standaard en aanbevolen stuurprogramma sinds PHP 5.4 is echter mysqlnd.

Beide drivers hebben veel voor- en nadelen. Echter, het verwijderen van ondersteuning voor een van hen – idealiter libmysql omdat het niet de standaard is – zal de code en eenheidstesten van PHP vereenvoudigen.

Om een case voor deze verwijdering te maken, somt de RFC vele voordelen van mysqlnd op:

  • Het is gebundeld met PHP
  • Het gebruikt PHP geheugenbeheer om het geheugengebruik te controleren en
    prestaties te verbeteren
  • Biedt quality-of-life functies (bijv. get_result())
  • Geeft numerieke waarden terug met behulp van PHP native types
  • De functionaliteit is niet afhankelijk van de externe bibliotheek
  • Optionele plugin-functionaliteit
  • Ondersteunt asynchrone queries

De RFC noemt ook enkele voordelen van libmysql, waaronder:

Daarnaast noemt de RFC veel nadelen van libmysql – incompatibiliteit met het PHP geheugenmodel, veel falende tests, geheugenlekken, verschillende functionaliteiten tussen versies, enz.

Met dit alles in gedachten verwijderde PHP 8.2 de ondersteuning voor het bouwen van mysqli tegen libmysql.

Als je een functionaliteit wilt toevoegen die alleen beschikbaar is met libmysql, moet je die expliciet toevoegen aan mysqlnd als een verzoek om een functie. Je kunt ook geen auto-reconnect toevoegen.

Locale-onafhankelijke case

Voor PHP 8.0 werd de locale van PHP geërfd van de systeemomgeving. Maar dit kon in sommige randgevallen een probleem opleveren.

Het instellen van de taal tijdens de installatie van Linux stelt de juiste gebruikersinterfacetaal in voor de ingebouwde commando’s. Het verandert echter ook onverwacht hoe de stringafhandeling van de C bibliotheek werkt.

Als je bijvoorbeeld de taal “Turks” of “Kazachs” hebt gekozen tijdens de installatie van Linux, zul je merken dat het aanroepen van toupper('i') om het equivalent in hoofdletters te krijgen, de gestippelde hoofdletter I oplevert (U+0130, İ).

PHP 8.0 heeft deze anomalie gestopt door de standaard locale op “C” te zetten, tenzij de gebruiker dit expliciet verandert via setlocale().

PHP 8.2 gaat nog verder door de locale gevoeligheid voor hoofdletterconversies weg te nemen. Deze RFC wijzigt voornamelijk strtolower(), strtoupper(), en verwante functies. Lees de RFC voor een lijst van alle betrokken functies.

Als alternatief kun je, als je gelokaliseerde case conversie wilt gebruiken, mb_strtolower() gebruiken.

Verbetering van de random extensie

PHP is van plan zijn random functionaliteit te herzien.

Op dit moment is PHP’s random functionaliteit sterk afhankelijk van de Mersenne Twister state. Deze state wordt echter impliciet opgeslagen in PHP’s globale gebied – een gebruiker kan er op geen enkele manier bij. Het toevoegen van randomisatiefuncties tussen de eerste fase van het zaaien en het bedoelde gebruik zou de code breken.

Het onderhouden van zulke code kan nog ingewikkelder zijn wanneer je code gebruik maakt van externe pakketten.

De huidige random functionaliteit van PHP kan dus geen willekeurige waarden consistent reproduceren. Hij faalt zelfs in empirische statistische tests van uniforme willekeurige getallengeneratoren, zoals TestU01’s Crush en BigCrush. De 32-bits beperking van Mersenne Twister maakt dat nog erger.

Het gebruik van PHP’s ingebouwde functies – shuffle(), str_shuffle(), array_rand() – is dus niet aan te raden als je cryptografisch veilige willekeurige getallen nodig hebt. In zulke gevallen zul je een nieuwe functie moeten implementeren met behulp van random_int() of soortgelijke functies.

Verschillende problemen met deze RFC werden echter naar voren gebracht nadat het stemmen was begonnen. Deze tegenslag dwong het PHP team om alle problemen in een aparte RFC te noteren, met een stemoptie voor elk probleem. Pas na het bereiken van een consensus zullen ze besluiten om verder te gaan.

Extra RFC’s in PHP 8.2

PHP 8.2 bevat ook veel nieuwe functies en kleine veranderingen. We noemen ze hieronder met links naar aanvullende bronnen:

  1. Nieuwe curl_upkeep functie: PHP 8.2 voegt deze nieuwe functie toe aan zijn Curl-extensie. Hij callt de functie curl_easy_upkeep() in libcurl, de onderliggende C-bibliotheek die de PHP Curl-extensie gebruikt.
  2. Nieuwe ini_parse_quantity functie: PHP INI directives accepteren gegevensgroottes met een vermenigvuldigingsachtervoegsel. Je kunt bijvoorbeeld 25 Megabyte schrijven als 25M, of 42 Gigabyte als gewoon 42G. Deze suffixen komen veel voor in PHP INI bestanden, maar zijn elders ongewoon. Deze nieuwe functie parseert de PHP INI waarden en geeft hun gegevensgrootte in bytes.
  3. Nieuwe memory_reset_peak_usage functie: Deze functie reset het piekgeheugengebruik dat de functie memory_get_peak_usage teruggeeft. Dit kan handig zijn als je dezelfde actie meerdere keren uitvoert en het piekgeheugengebruik van elke keer wilt bijhouden.
  4. Ondersteuning voor no-capture modifier (/n) in preg_* functies: In regex geven de metacharacters () een catch groep aan. Dat betekent dat alle overeenkomsten voor de expressions binnen het haakje worden geretourneerd. PHP 8.2 voegt een no-capture modifier (/n) toe om dit gedrag te stoppen.
  5. Laat de iterator_*() familie alle iterables accepteren: Op dit moment accepteert PHP’s iterator_*() familie alleen Traversables (dus geen gewone arrays toegestaan). Dat is onnodig beperkend, en deze RFC lost dat op.

Samenvatting

PHP 8.2 bouwt voort op de enorme verbeteringen in PHP 8.0 en PHP 8.1, en dat is geen gemakkelijke opgave. De meest spannende functies van PHP 8.2 zijn volgens ons de nieuwe standalone types, readonly properties en talrijke prestatieverbeteringen.

We kunnen niet wachten om PHP 8.2 te benchmarken met verschillende PHP frameworks en CMS’en.

Zorg ervoor dat je deze blogpost bladwijzert voor toekomstig gebruik.

Welke functies van PHP 8.2 zijn jouw favoriet? Welke afschrijvingen zijn je minst favoriete? Deel je gedachten met onze community in de comments!

Salman Ravoof

Salman Ravoof is een autodidactische webdeveloper, schrijver, creator en een groot bewonderaar van Free and Open Source Software (FOSS). Naast techniek is hij enthousiast over wetenschap, filosofie, fotografie, kunst, katten en eten. Lees meer over hem op zijn website en kom in contact met Salman op X.