PHP 8.2 bygger på den fornyede base, der er fremsat af PHP 8.0 og PHP 8.1. Nu hvor PHP 8.2 er blevet frigivet, lad os dække, hvad der er nyt i PHP 8.2 i detaljer – fra dets nye funktioner og forbedringer til afskrivninger og mindre ændringer, vi vil gennemgå dem alle.

Da PHP 8.2 gik ind i sin funktionsfrysning den 19. juli 2022, kan du ikke forvente nogen væsentlige tilføjelser til denne liste.

Er du spændt? Det er vi også.

Lad os begynde!

Nye funktioner og forbedringer i PHP 8.2

Lad os starte med at udforske alle de nyeste funktioner i PHP 8.2. Det er en ret omfattende liste:

Nye readonly klasser

PHP 8.1 introducerede readonly -funktionen for klasseegenskaber. Nu tilføjer PHP 8.2 understøttelse af at deklarere hele klassen som readonly.

Hvis du erklærer en klasse som readonly, vil alle dens egenskaber automatisk arve readonly -funktionen. At deklarere en klasse readonly er således det samme som at deklarere alle klassens egenskaber som readonly.

Med PHP 8.1 var man f.eks. nødt til at skrive denne kedelige kode for at deklarere alle klassens egenskaber som readonly:

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

Forestil dig det samme med mange flere egenskaber. Nu, med PHP 8.2, kan du bare skrive dette:

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

Du kan også erklære abstrakte eller endelige klasser som readonly. Her er rækkefølgen af nøgleordene ligegyldig.

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

Du kan også deklarere en readonly klasse uden egenskaber. Dette forhindrer dynamiske egenskaber, men giver stadig mulighed for, at underklasser kan deklarere deres readonly egenskaber eksplicit.

Næste punkt er, at readonly -klasser kun kan indeholde typede egenskaber – den samme regel for deklaration af individuelle skrivebeskyttede egenskaber.

Du kan bruge mixed typeegenskaben, hvis du ikke kan deklarere en stricht typet egenskab.

Hvis du forsøger at deklarere en readonly -klasse uden en typet egenskab, vil det resultere i en Fatal error:

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

Desuden kan du ikke deklarere readonly for visse PHP-funktioner:

Forsøg på at deklarere en af disse funktioner som readonly vil resultere i en Parse-fejl.

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

Som det er tilfældet for alle PHP-keywords, er readonly keywordet ikke gengivet med hensyn til store og små bogstaver.

PHP 8.2 forælder også dynamiske egenskaber (mere om det senere). Men du kan ikke forhindre, at der tilføjes dynamiske egenskaber til en klasse. Men hvis du gør det for en readonly -klasse, vil det kun resultere i en Fatal Error.

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

Tillad true, false, og null som selvstændige typer

PHP indeholder allerede skalartyper som int, string, og bool. Dette blev udvidet i PHP 8.0 med tilføjelsen af unionstyper, som gør det muligt at have værdier af forskellige typer. Samme RFC tillod også at bruge false og null som en del af en union-type – de var dog ikke tilladt som selvstændige typer.

Hvis du forsøgte at deklarere false eller null som selvstændige typer – uden at de var en del af en union-type – resulterede det i en fatal error.

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

For at undgå dette scenarie tilføjes der i PHP 8.2 understøttelse for at bruge false og null som selvstændige typer. Med denne tilføjelse er PHP’s typesystem mere udtryksfuldt og komplet. Du kan nu deklarere returnerings-, parameter- og egenskabstyperne præcist.

Desuden indeholder PHP stadig ikke en true -type, som synes at være en naturlig modpart til false -typen. PHP 8.2 retter dette og tilføjer også understøttelse for typen true. Den tillader ikke coercion, nøjagtig som false -typen opfører sig.

Både true – og false -typerne er i det væsentlige en unionstype af PHP’s bool -type. For at undgå redundans kan du ikke deklarere disse tre typer sammen i en unionstype. Hvis du gør det, vil det resultere i en fatal error i kompileringstiden.

DNF-typer (Disjunctive Normal Form)

Disjunktiv normalform (DNF) er en standardiseret måde at organisere boolske udtryk på. Den består af en disjunktion af konjunktioner – i boolske termer er det en OR af AND’er.

Anvendelse af DNF på typedeklarationer giver mulighed for en standardiseret måde at skrive kombinerede Union- og Intersection-typer på, som parseren kan håndtere. PHP 8.2’s nye DNF-typer-funktion er enkel, men kraftfuld, hvis den bruges korrekt.

I RFC’en gives følgende eksempel. Det antager, at følgende grænseflade- og klassedefinitioner allerede findes:

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

Med DNF-typer kan du udføre typedeklarationer for egenskaber, parametre og returværdier på følgende måde:

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

I nogle tilfælde er egenskaberne ikke nødvendigvis i DNF-former. Hvis de deklareres som sådan, vil det resultere i en parsefejl. Men du kan altid omskrive dem som:

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

Du skal være opmærksom på, at hvert segment af en DNF-type skal være unikt. For eksempel er det ugyldigt at deklarere (A&B)|(B&A), da de to ORed-segmenter logisk set er de samme.

Hertil kommer, at segmenter, der er strenge delmængder af det andet segment, heller ikke er tilladt. Det skyldes, at overmængden allerede vil have alle forekomster af undermængden, hvilket gør det overflødigt at bruge DNF.

Redaktér følsomme parametre i backtraces

Som næsten alle programmeringssprog tillader PHP at spore sin call stack på ethvert tidspunkt i kodens udførelse. Staksporing gør det nemt at fejlfinde kode for at rette fejl og flaskehalse i ydelsen. Det udgør rygraden i værktøjer som Kinsta APM, vores specialudviklede værktøj til overvågning af ydeevne for WordPress-websteder.

Sporing af langsomme WooCommerce-transaktioner med Kinsta APM.
Sporing af langsomme WooCommerce-transaktioner med Kinsta APM.

Udførelse af en stack trace stopper ikke programmets udførelse. Typisk kører de fleste stack traces i baggrunden og logges lydløst – til senere inspektion, hvis det er nødvendigt.

Nogle af disse detaljerede PHP stack traces kan dog være en ulempe, hvis du deler dem med tredjepartstjenester – normalt med henblik på fejl-loganalyse, fejlsporing osv. Disse stack traces kan indeholde følsomme oplysninger som brugernavne, passwords og miljøvariabler.

Dette RFC-forslag giver et sådant eksempel:

En almindelig “synder” er PDO, som tager databasens password som en konstruktørparameter og straks forsøger at oprette forbindelse til databasen i konstruktøren i stedet for at have en ren konstruktør og en separat ->connect() -metode. Når databaseforbindelsen mislykkes, vil stack trace’en således indeholde databasens password:

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 giver mulighed for at markere sådanne følsomme parametre med en ny SensitiveParameter -attribut. Alle parametre, der er markeret som følsomme, vil ikke blive opført i dine backtraces. Du kan således dele dem uden problemer med tredjepartstjenester.

Her er et simpelt eksempel med en enkelt følsom 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
*/

Når du genererer en backtrace, vil enhver parameter med attributten SensitiveParameter blive erstattet med et SensitiveParameterValue -objekt, og dens reelle værdi vil aldrig blive gemt i sporingen. SensitiveParameterValue -objektet indkapsler den faktiske parameterværdi – hvis du har brug for den af en eller anden grund.

Ny mysqli_execute_query -funktion og mysqli::execute_query -metode

Har du nogensinde brugt mysqli_query() -funktionen med faretruende escaping-brugerværdier, bare for at køre en parameteriseret MySQLi-forespørgsel?

PHP 8.2 gør det nemmere at køre parameteriserede MySQLi-forespørgsler med den nye mysqli_execute_query($sql, $params) -funktion og mysqli::execute_query -metode.

Denne nye funktion er i det væsentlige en kombination af funktionerne mysqli_prepare(), mysqli_execute() og mysqli_stmt_get_result(). Med den vil MySQLi-forespørgslen blive forberedt, bundet (hvis du angiver parametre) og udført inden for selve funktionen. Hvis forespørgslen kører med succes, returnerer den et mysqli_result objekt. Hvis det ikke lykkes, returnerer den false.

RFC-forslaget giver et enkelt, men effektivt eksempel:

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

Hent enum Egenskaber i const Udtryk

Idenne RFC foreslås det at tillade operatoren ->/?-> at hente enum egenskaber i const -udtryk.

Hovedårsagen til denne nye funktion er, at man ikke kan bruge enum -objekter på visse steder, f.eks. i array-nøgler. I et sådant tilfælde skal du gentage værdien af enum -objektet bare for at bruge det.

Ved at tillade hentning af enum -egenskaber på steder, hvor enum -objekter ikke er tilladt, kan man forenkle denne procedure.

Det betyder, at følgende kode nu er gyldig:

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

Og for en sikkerheds skyld indeholder denne RFC også understøttelse af nullsafe-operatoren ?->.

Tillad konstanter i egenskaber

PHP indeholder en måde at genbruge kode på, der kaldes Traits. De er gode til genbrug af kode på tværs af klasser.

I øjeblikket tillader Traits kun at definere metoder og egenskaber, men ikke konstanter. Det betyder, at du ikke kan definere invarianter, der forventes af en Trait, i selve Trait’en. For at omgå denne begrænsning skal du definere konstanter i den sammensættende klasse eller i en grænseflade, der er implementeret af den sammensættende klasse.

I denne RFC foreslås det, at det skal være muligt at definere konstanter i Traits. Disse konstanter kan defineres på samme måde, som man definerer klassekonstanter. Dette eksempel, der er taget direkte fra RFC’en, gør det klart, hvordan det skal bruges:

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-konstanterne er også integreret i den sammensættende klasses definition, på samme måde som en Traits egenskabs- og metodefinitioner. De har også de samme begrænsninger som egenskaber for Traits. Som nævnt i RFC’en skal der arbejdes videre med dette forslag – selv om det er en god start – for at uddybe funktionen.

Forældelser i PHP 8.2

Vi kan nu gå over til at undersøge alle deprecations i PHP 8.2. Denne liste er ikke helt så stor som dens nye funktioner:

Forældelse af dynamiske egenskaber (og ny #[AllowDynamicProperties] Attribut)

Indtil PHP 8.1 kunne du dynamisk indstille og hente ikke-deklarerede klasseegenskaber dynamisk i PHP. For eksempel:

class Post {
    private int $pid;
}

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

Her erklærer klassen Post ikke en name -egenskab. Men da PHP tillader dynamiske egenskaber, kan du indstille den uden for klassedeklarationen. Det er dens største – og muligvis den eneste – fordel.

Dynamiske egenskaber gør det muligt at få uventede fejl og uventet adfærd til at dukke op i din kode. Hvis du f.eks. begår en fejl, mens du deklarerer en klasseegenskab uden for klassen, er det let at miste overblikket over den – især når du debugger eventuelle fejl i den pågældende klasse.

Fra og med PHP 8.2 er dynamiske egenskaber forældet. Hvis du sætter en værdi til en ikke-deklareret klasseegenskab vil der blive udsendt en deprecation notice første gang egenskaben sættes.

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;

Men fra og med PHP 9.0 og fremefter vil indstillingen af det samme give en ErrorException -fejl.

Hvis din kode er fuld af dynamiske egenskaber – og det er der meget PHP-kode, der er – og hvis du ønsker at stoppe disse deprecation-meddelelser efter opgradering til PHP 8.2, kan du bruge PHP 8.2’s nye #[AllowDynamicProperties] -attribut til at tillade dynamiske egenskaber på klasser.

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

Ifølge RFC’en kan klasser markeret som #[AllowDynamicProperties], samt deres underklasser, fortsat bruge dynamiske egenskaber uden deprecering eller fjernelse.

Du bør også bemærke, at i PHP 8.2 er stdClass den eneste klasse, der er markeret som #[AllowDynamicProperties], den eneste klasse i bundtet. Desuden betragtes alle egenskaber, der tilgås via __get() eller __set() PHP magic-metoder, ikke som dynamiske egenskaber, så de vil ikke give en meddelelse om deprecering.

Udgå delvist understøttede Callables

En anden ændring i PHP 8.2, om end med en mere ubetydelig virkning, er at deprecate delvist understøttede callables.

Disse callables kaldes delvist understøttede, fordi du ikke kan interagere med dem direkte via $callable(). Du kan kun få adgang til dem med funktionen call_user_func($callable). Listen over sådanne callables er ikke lang:

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

Fra og med PHP 8.2 og fremefter vil ethvert forsøg på at kalde sådanne callables – f.eks. via funktionerne call_user_func() eller array_map() – give en deprecation-advarsel.

Den oprindelige RFC giver en solid begrundelse for denne deprecering:

Bortset fra de to sidste tilfælde er alle disse callables kontekstafhængige. Den metode, som "self::method" henviser til, afhænger af, hvilken klasse opkaldet eller kontrollen af opkaldsegnetheden udføres fra. I praksis gælder dette normalt også for de to sidste tilfælde, når de anvendes i form af [new Foo, "parent::method"].

Reduktion af kontekstafhængigheden af callables er det sekundære mål med denne RFC. Efter denne RFC er den eneste scope-afhængighed, der stadig er tilbage, metoders synlighed: "Foo::bar" kan være synlig i ét scope, men ikke i et andet. Hvis callables fremover begrænses til offentlige metoder (mens private metoder skal anvende første klasses callables eller Closure::fromCallable() for at blive uafhængige af anvendelsesområdet), vil callable-typen blive veldefineret og kunne anvendes som egenskabstype. Der foreslås dog ikke ændringer i håndteringen af synlighed som led i denne RFC

.
I overensstemmelse med den oprindelige RFC vil is_callable() -funktionen og callable -typen fortsat acceptere disse callables som undtagelser. Men kun indtil understøttelsen af dem fjernes helt fra PHP 9.0 og fremefter.

For at undgå forvirring blev omfanget af denne deprecation notice udvidet med en ny RFC – den omfatter nu disse undtagelser.

Det er godt at se, at PHP bevæger sig i retning af at have en veldefineret callable type.

Forældelse af funktionerne #utf8_encode() og utf8_decode()

PHP’s indbyggede funktioner utf8_encode() og utf8_decode() konverterer strenge kodet i ISO-8859-1 (“Latin 1”) til og fra UTF-8.

Deres navne antyder dog en mere generel anvendelse end deres implementering tillader. “Latin 1”-kodningen forveksles ofte med andre kodninger som f.eks. “Windows Code Page 1252”

Desuden vil du normalt se Mojibake, når disse funktioner ikke kan konvertere nogen stricht korrekt. Manglen på fejlmeddelelser betyder også, at det er svært at få øje på dem, især i et hav af ellers læselig tekst.

PHP 8.2 forældet både #utf8_encode() og utf8_decode() funktionerne. Hvis du påkalder dem, vil du se disse deprecation notices:

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

RFC foreslår, at du i stedet bruger PHP’s understøttede udvidelser som mbstring, iconv og intl.

Forældelse af ${} String Interpolation

PHP tillader indlejring af variabler i strungs med dobbelte anførselstegn (") og heredoc (<<<) på flere måder:

  1. Direkte indlejring af variabler – “$foo”
  2. Med parenteser uden for variablen – “{$foo}”
  3. Med parenteser efter dollartegnet – “${foo}”
  4. Variable variabler – “${expr}” – svarer til at bruge (string) ${expr}

De to første måder har deres fordele og ulemper, mens de to sidstnævnte har en kompleks og modstridende syntaks. PHP 8.2 forælder de to sidste måder at interpolere strenge på.

Du bør holde dig fra at interpolere strenge på denne måde fremover:

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

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

Fra og med PHP 9.0 vil disse deprecations blive opgraderet til at kaste en undtagelsesfejl.

Forældelse af mbstring-funktioner for Base64/QPrint/Uuencode/HTML-enheder

PHP’s mbstring-funktioner (multi-byte string) hjælper os med at arbejde med Unicode, HTML-enheder og andre ældre tekstkodninger.

Base64, Uuencode og QPrint er dog ikke tekstkodninger og er stadig en del af disse funktioner – primært af legacy-grunde. PHP indeholder også separate implementeringer af disse kodninger.

Hvad angår HTML-enheder, har PHP indbyggede funktioner – htmlspecialchars() og htmlentities() – til at håndtere disse bedre. I modsætning til mbstring vil disse funktioner f.eks. også konvertere <. >, og & -tegn til HTML-entiteter.

Desuden forbedrer PHP hele tiden sine indbyggede funktioner – ligesom PHP 8.1 med HTML-kodnings- og afkodningsfunktioner.

Så med alt dette in mente, forkaster PHP 8.2 brugen af mbstring til disse kodninger (etiketterne er ikke skivende):

  • BASE64
  • UUENCODE
  • HTML-ENTITIES
  • html (alias for HTML-ENTITIES)
  • Anførselstegn-udskrivbar
  • qprint (alias for Quoted-Printable)

Fra og med PHP 8.2 vil brugen af mbstring til kodning/afkodning af en af ovenstående kodninger give en deprecation notice. PHP 9.0 vil fjerne mbstring-understøttelse for disse kodninger helt og holdent.

Andre mindre ændringer i PHP 8.2

Endelig kan vi diskutere PHP 8.2’s mindre ændringer, herunder de fjernede funktioner.

Fjern understøttelse af libmysql fra mysqli

Fra nu af tillader PHP både mysqli – og PDO_mysql -drivere at bygge mod mysqlnd – og libmysql -bibliotekerne. Standarddriveren og den anbefalede driver siden PHP 5.4 har dog været mysqlnd.

Begge disse drivere har mange fordele og ulemper. Men hvis man fjerner understøttelsen af en af dem – ideelt set fjerner man libmysql, da det ikke er standard – vil det forenkle PHP’s kode og enhedstests.

For at argumentere for denne fordel, opregner RFC’en mange fordele ved mysqlnd:

  • Det er pakket med PHP
  • Det bruger PHP-hukommelsesstyring til at overvåge hukommelsesforbruget og
    forbedre ydeevnen
  • Giver funktioner til at sikre livskvalitet (f.eks. get_result())
  • Returnerer numeriske værdier ved hjælp af PHP’s native typer
  • Dens funktionalitet er ikke afhængig af det eksterne bibliotek
  • Valgfri plugin-funktionalitet
  • Understøtter asynkrone forespørgsler

RFC’en opregner også nogle fordele ved libmysql, herunder:

  • Auto-reconnect er muligt (mysqlnd understøtter ikke denne funktionalitet med vilje, fordi den let kan udnyttes)
  • LDAP- og SASL-godkendelsestilstande (mysqlnd tilføjer muligvis også snart denne funktion )

Desuden nævner RFC’en mange ulemper ved libmysql – inkompatibilitet med PHP’s hukommelsesmodel, mange fejlslagne tests, hukommelseslækager, forskellige funktionaliteter fra version til version osv.

Med alt dette in mente fjernede PHP 8.2 understøttelsen af at bygge mysqli mod libmysql.

Hvis du ønsker at tilføje en funktionalitet, der kun er tilgængelig med libmysql, skal du tilføje den eksplicit til mysqlnd som en feature request. Du kan heller ikke tilføje auto-reconnect.

Lokalitetsuafhængig case-konvertering

Før PHP 8.0 blev PHP’s locale arvet fra systemmiljøet. Men dette kunne give problemer i nogle edge-tilfælde.

Hvis du indstiller dit sprog, mens du installerer Linux, vil du indstille det passende sprog for brugergrænsefladen for de indbyggede kommandoer. Det ændrer dog også uventet hvordan C-bibliotekets strenghåndteringsfunktionalitet fungerer.

Hvis du f.eks. har valgt sproget “tyrkisk” eller “kasakhisk”, da du installerede Linux, vil du opdage, at hvis du kalder toupper('i') for at få det tilsvarende store bogstav, vil du få det prikkede store I (U+0130, İ).

PHP 8.0 har stoppet denne uregelmæssighed ved at indstille standardlokalskalaen til “C”, medmindre brugeren udtrykkeligt ændrer den via setlocale().

PHP 8.2 går endnu længere ved at fjerne lokalfølsomhed fra konvertering af store og små bogstaver. Denne RFC ændrer primært strtolower(), strtoupper() og relaterede funktioner. Læs RFC’en for at få en liste over alle de berørte funktioner.

Som et alternativ kan du bruge mb_strtolower(), hvis du ønsker at bruge lokaliseret konvertering af store og små bogstaver.

Forbedring af tilfældig udvidelse

PHP har planer om at gennemgå sin tilfældige funktionalitet.

Som det er nu, er PHP’s tilfældige funktionalitet stærkt afhængig af Mersenne Twister-tilstanden. Denne tilstand er imidlertid implicit gemt i PHP’s globale område – der er ingen måde, hvorpå en bruger kan få adgang til den. Tilføjelse af randomiserings-funktioner mellem den indledende seedningsfase og den tilsigtede brug ville ødelægge koden.

Vedligeholdelse af en sådan kode kan være endnu mere kompliceret, når din kode bruger eksterne pakker.

PHP’s nuværende tilfældige funktionalitet kan således ikke reproducere tilfældige værdier på en konsekvent måde. Den fejler endda i empiriske statistiske tests af ensartede tilfældige talgeneratorer, som TestU01’s Crush og BigCrush. Mersenne Twister’s 32-bit begrænsning forværrer dette yderligere.

Derfor anbefales det ikke at bruge PHP’s indbyggede funktioner – shuffle(), str_shuffle(), array_rand() – hvis du har brug for kryptografisk sikre tilfældige tal. I sådanne tilfælde skal du implementere en ny funktion ved hjælp af random_int() eller lignende funktioner.

Der blev imidlertid rejst flere problemer med denne RFC efter at afstemningen var begyndt. Dette tilbageslag tvang PHP-holdet til at notere alle problemerne i en separat RFC, hvor der blev oprettet en afstemningsmulighed for hvert problem. De vil først beslutte at gå videre, når der er opnået konsensus.

Yderligere RFC’er i PHP 8.2

PHP 8.2 indeholder også mange nye funktioner og mindre ændringer. Vi nævner dem nedenfor med links til yderligere ressourcer:

  1. Ny curl_upkeep funktion: PHP 8.2 tilføjer denne nye funktion til sin Curl-udvidelse. Den kalder curl_easy_upkeep() -funktionen i libcurl, det underliggende C-bibliotek, som PHP Curl-udvidelsen bruger.
  2. Ny ini_parse_quantity -funktion: PHP INI-direktiver accepterer datastørrelser med et multiplikator-suffiks. Du kan f.eks. skrive 25 megabyte som 25M, eller 42 gigabyte som bare 42G. Disse suffikser er almindelige i PHP INI-filer, men er ualmindelige andre steder. Denne nye funktion analyserer PHP INI-værdierne og returnerer deres datastørrelse i bytes.
  3. Ny funktion memory_reset_peak_usage: Denne funktion nulstiller det maksimale hukommelsesforbrug, der returneres af memory_get_peak_usage -funktionen. Det kan være praktisk, når du kører den samme handling flere gange og ønsker at registrere hver enkelt kørsels maksimale hukommelsesforbrug.
  4. Understøttelse af no-capture-modifikator (/n) i preg_* -funktioner: I regex angiver metakendetegn () en opfangende gruppe. Det betyder, at alle matches for udtrykket inden for parentesen returneres. PHP 8.2 tilføjer en no-capture-modifikator (/n) for at stoppe denne adfærd.
  5. Få iterator_*() -familien til at acceptere alle iterables: Som det er nu, accepterer PHP’s iterator_*() -familie kun Traversables (dvs. ingen almindelige arrays er tilladt). Det er unødvendigt begrænsende, og denne RFC retter det.

Opsummering

PHP 8.2 bygger videre på de massive forbedringer i PHP 8.0 og PHP 8.1, hvilket ikke er nogen let opgave. Vi mener, at de mest spændende funktioner i PHP 8.2 er de nye standalone-typer, readonly properties og de mange forbedringer af ydeevnen.

Vi kan ikke vente med at benchmarke PHP 8.2 med forskellige PHP-frameworks og CMS’er.

Sørg for at bogmærke dette blogindlæg til fremtidig reference.

Hvilke PHP 8.2-funktioner er dine foretrukne? Hvilke deprecations er dine mindst foretrukne? Del dine tanker med vores fællesskab i kommentarerne!

Salman Ravoof

Han er en selvlært webudvikler, skribent, skaber og en stor beundrer af Free and Open Source Software (FOSS). Udover teknologi, er han begejstret for videnskab, filosofi, fotografi, kunst, katte og mad. Lær mere om ham på hans hjemmeside, og kontakt Salman på X.