PHP 8.2 bygger på den förnyade basen från PHP 8.0 och PHP 8.1. Nu när PHP 8.2 har släppts, ska vi gå igenom vad som är nytt i PHP 8.2 i detalj – från dess nya funktioner och förbättringar till utfasningar och mindre ändringar, vi kommer att gå igenom dem alla.
Eftersom PHP 8.2 gick in i sin funktionsfrysning den 19 juli år 2022 kan du inte förvänta dig några större tillägg till den här listan.
Är du spänd? Det är vi också.
Låt oss börja!
Nya funktioner och förbättringar i PHP 8.2
Låt oss börja med att utforska alla de senaste funktionerna i PHP 8.2. Det är en ganska omfattande lista:
Nya readonly klasser
I PHP 8.1 introducerades funktionenreadonly för klassegenskaper. Nu lägger PHP 8.2 till stöd för att deklarera hela klassen som readonly.
Om du deklarerar en klass som readonly kommer alla dess egenskaper automatiskt att ärva funktionen readonly. Att deklarera en klass readonly är alltså detsamma som att deklarera varje klassegenskap som readonly.
Med PHP 8.1 var du exempelvis tvungen att skriva denna tråkiga kod för att deklarera alla klassegenskaper som readonly:
class MyClass
{
public readonly string $myValue,
public readonly int $myOtherValue
public readonly string $myAnotherValue
public readonly int $myYetAnotherValue
}Föreställ dig samma sak med många fler egenskaper. Nu, med PHP 8.2, räcker det om du skriver detta:
readonly class MyClass
{
public string $myValue,
public int $myOtherValue
public string $myAnotherValue
public int $myYetAnotherValue
}Du kan även deklarera abstrakta eller slutgiltiga klasser som readonly. Här spelar ordningsföljden på nyckelorden ingen roll.
abstract readonly class Free {}
final readonly class Dom {}Du kan även deklarera en readonly -klass utan egenskaper. Detta förhindrar dynamiska egenskaper, men gör det ändå möjligt för underklasser att deklarera sina readonly-egenskaper .
Nästa steg är att readonly -klasser endast kan innehålla typade egenskaper — samma regel som för att deklarera enskilda readonly-egenskaper.
Du kan använda typegenskapen mixed om du inte kan deklarera en strikt typad egenskap.
Om du försöker att deklarera en readonly -klass utan en typad egenskap kommer detta att resultera i ett fel:
readonly class Type {
public $nope;
}
Fatal error: Readonly property Type::$nope must have type in ... on line ... Du kan inte heller deklarera readonly för vissa PHP-funktioner:
- Enums (eftersom de inte kan innehålla någon egenskap)
- Traits
- Gränssnitt
Om du försöker att deklarera någon av dessa funktioner som readonly kommer detta att resultera i ett fel i analysen.
readonly interface Destiny {}
Parse error: syntax error, unexpected token "interface", expecting "abstract" or "final" or "readonly" or "class" in ... on line ...Precis som för alla PHP-nyckelord är nyckelordet readonly okänsligt för storleken på skiftläget.
PHP 8.2 avskaffar även dynamiska egenskaper (mer om detta senare). Men du kan inte förhindra att dynamiska egenskaper läggs till i en klass. Att göra detta för en readonly -klass resulterar dock bara i ett fel.
Fatal error: Readonly property Test::$test must have type in ... on line ...Tillåt true, false och null som fristående typer
PHP innehåller redan skalära typer som int, string och bool. Detta utökades i PHP 8.0 med unionstyper som gör det möjligt för värden att vara av olika typer. I samma RFC tillåts även att false och null används som en del av en unionstyp — de tillåts dock inte som fristående typer.
Om du försökte deklarera false eller null som fristående typer — utan att de var en del av en unionstyp — resulterade detta i ett fel.
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 ...För att undvika detta scenario har PHP 8.2 lagt till stöd för att använda false och null som fristående typer. Med detta tillägg blir PHP:s typsystem mer uttrycksfullt och komplett. Du kan nu deklarera retur-, parameter- och egenskapstyperna exakt.
Dessutom innehåller PHP fortfarande inte en true -typ, som verkar vara en naturlig motsvarighet till false -typen. PHP 8.2 åtgärdar detta och lägger till stöd även för typen true. Den tillåter inte coercion, som fungerar precis som typen false.
Både typerna true och false är i huvudsak en unionstyp av PHP:s typ bool. För att undvika redundans kan du inte deklarera dessa tre typer tillsammans i en unionstyp. Om du gör detta kommer det att resultera i ett fel under kompileringstiden.
DNF-typer (Disjunctive Normal Form)
Disjunctive Normal Form (DNF) är ett standardiserat sätt att organisera boolska uttryck. Det består av en disjunktion av konjunktioner — i boolska termer är det en OR av ANDs.
Genom att tillämpa DNF på typdeklarationer så kan man på ett standardiserat sätt skriva kombinerade Union- och Intersection-typer som tolkaren kan hantera. PHP 8.2:s nya funktion för DNF-typer är enkel men kraftfull om den används på rätt sätt.
I RFC ges följande exempel. Det förutsätter att följande gränssnitts- och klassdefinitioner redan finns:
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 utföra typdeklarationer för egenskaper, parametrar och returvärden på följande sätt:
// 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|nullI vissa fall kan egenskaperna inte vara i DNF-form. Att deklarera dem som sådana kommer att resultera i ett tolkningsfel. Men du kan alltid skriva om 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)|nullDu bör notera att varje segment av en DNF-typ måste vara unikt. Att deklarera (A&B)|(B&A) är till exempel ogiltigt eftersom de två ORed-segmenten är logiskt sett samma.
Dessutom är segment som är strikta delmängder av det andra segmentet inte heller tillåtna. Detta beror på att övermängden redan kommer att ha alla instanser av undermängden, vilket gör det överflödigt att använda DNF.
Redakturera känsliga parametrar i tillbakaspår
Liksom nästan alla programmeringsspråk tillåter PHP spårning av anropsstacken när som helst under kodens exekvering. Stack-spårning gör det enkelt att felsöka kod för att åtgärda fel och flaskhalsar i prestanda. Det utgör ryggraden i verktyg som Kinsta APM, vårt specialutvecklade verktyg för övervakning av prestanda för WordPress-webbplatser.
Att utföra en stackspårning stoppar inte programmets exekvering. Typiskt sett körs de flesta stackspårningar i bakgrunden och loggas tyst — för senare inspektion om det krävs.
Vissa av dessa detaljerade PHP-stackspårare kan dock vara en nackdel om du delar dem med tredjepartstjänster — vanligtvis för analys av felloggar, felspårning osv. Dessa stackspårare kan innehålla känslig information som användarnamn, lösenord och miljövariabler.
I detta RFC-förslag ges ett sådant exempel:
En vanlig ”brottsling” är PDO som tar databasens lösenord som en konstruktörsparameter och omedelbart försöker ansluta till databasen i konstruktören, i stället för att ha en ren konstruktör och en separat ->connect()-metod. När databasanslutningen misslyckas kommer stackspårningen att innehålla databaslösenordet:
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 gör det möjligt att markera sådana känsliga parametrar med det nya attributet SensitiveParameter. Alla parametrar som är markerade som känsliga kommer inte att listas i dina tillbakaspårningar. På så sätt kan du dela dem utan problem med tredjepartstjänster.
Här är ett enkelt exempel med en enda känslig 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 genererar en bakåtspårning kommer alla parametrar med attributet \SensitiveParameter att ersättas med ett \SensitiveParameterValue -objekt, och dess verkliga värde kommer aldrig att lagras i spårningen. Objektet SensitiveParameterValue kapslar in det faktiska parametervärdet — om du behöver det av någon anledning.
Ny funktion mysqli_execute_query och metod mysqli::execute_query
Har du någonsin använt mysqli_query() -funktionen med farligt undanglidande användarvärden bara för att köra en parameterstyrd MySQLi-fråga?
PHP 8.2 gör det enklare att köra parameterbaserade MySQLi-frågor med den nya funktionen mysqli_execute_query($sql, $params) och metoden mysqli::execute_query.
Den nya funktionen är i huvudsak en kombination av funktionerna mysqli_prepare(), mysqli_execute() och mysqli_stmt_get_result(). Med den kommer MySQLi-frågan att förberedas, bindas (om du skickar några parametrar) och exekveras inom själva funktionen. Om frågan körs framgångsrikt returneras ett mysqli_result -objekt. Om den inte lyckas returnerar den false.
RFC-förslaget ger ett enkelt men kraftfullt exempel:
foreach ($db->execute_query('SELECT * FROM user WHERE name LIKE ? AND type_id IN (?, ?)', [$name, $type1, $type2]) as $row) {
print_r($row);
}Hämta enum-egenskaper i const-uttryck
I detta RFC föreslås att ->/?-> -operatören ska kunna hämta enum-egenskaper i const-uttryck.
Huvudskälet till denna nya funktion är att man inte kan använda enum-objekt på vissa ställen, t.ex. i array-nycklar. I sådana fall måste du upprepa värdet i enum-fallet bara för att använda det.
Genom att tillåta hämtning av enum-egenskaper på ställen där enum-objekt inte är tillåtna kan detta förfarande förenklas.
Det innebär att följande kod nu är giltig:
const C = [self::B->value => self::B];Denna RFC inkluderar för säkerhets skull även stöd för nullsafe-operatören ?->.
Tillåt konstanter i egenskaper
PHP inkluderar ett sätt att återanvända kod som kallas Traits. De är utmärkta för återanvändning av kod i olika klasser.
För närvarande tillåter Traits endast att man definierar metoder och egenskaper, men inte konstanter. Detta betyder att du inte kan definiera in varianter som förväntas av en Trait i själva Trait. För att kringgå denna begränsning måste du definiera konstanter i den komponerande klassen eller i ett gränssnitt som implementeras av den komponerande klassen.
I detta RFC föreslås att det ska vara möjligt att definiera konstanter i Traits. Dessa konstanter kan definieras på samma sätt som man definierar klasskonstanter. Det här exemplet, som är hämtat direkt från RFC, klargör användningen:
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-konstanter slås även samman med den sammansatta klassens definition, på samma sätt som en Traits egenskaps- och metoddefinitioner. De har även liknande begränsningar som egenskaper för Traits. Som noteras i RFC behöver detta förslag — även om det är en bra början — ytterligare arbete för att utveckla funktionen.
Avskrivningar i PHP 8.2
Vi kan nu gå över till att utforska alla avskrivningar i PHP 8.2. Den här listan är inte lika stor som de nya funktionerna:
Avskaffa dynamiska egenskaper (och nytt attribut #[AllowDynamicProperties])
Fram till PHP 8.1 kunde du ställa in och hämta odeklarerade klassegenskaper dynamiskt i PHP. Till exempel:
class Post {
private int $pid;
}
$post = new Post();
$post->name = 'Kinsta';Här har klassen Post inte deklarerat en name-egenskap. Men eftersom PHP tillåter dynamiska egenskaper så kan du ange den utanför klassdeklarationen. Det är dess största — och kanske enda — fördel.
Dynamiska egenskaper gör att oväntade fel och beteenden kan dyka upp i din kod. Om du exempelvis gör något misstag när du deklarerar en klassegenskap utanför klassen så är det lätt att tappa bort den — särskilt när du felsöker eventuella fel inom klassen.
Från och med PHP 8.2 är dynamiska egenskaper förlegade. Om du ställer in ett värde på en odeklarerad klassegenskap så kommer ett meddelande om avskrivning att skickas ut första gången som egenskapen ställs in.
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;Från och med PHP 9.0 och framåt kommer dock ett ErrorException-fel att uppstå när samma egenskap sätts.
Om din kod är full av dynamiska egenskaper — och det finns mycket PHP-kod som är det — och du vill stoppa dessa avskrivningsmeddelanden efter uppgradering till PHP 8.2 så kan du använda PHP 8.2:s nya attribut #[AllowDynamicProperties] för att tillåta dynamiska egenskaper 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;Enligt RFC kan klasser som är markerade som #[AllowDynamicProperties], liksom deras underklasser, fortsätta att använda dynamiska egenskaper utan att avskrivning eller borttagning sker.
Du bör även notera att i PHP 8.2 är stdClass den enda klass som är markerad som #[AllowDynamicProperties]. Egenskaper som nås med hjälp av __get() eller __set() magiska PHP-metoder betraktas inte som dynamiska egenskaper, vilket innebär att de inte kommer att ge upphov till ett meddelande om avskrivning.
Avskriv delvis stödda Callables
En annan ändring i PHP 8.2, om än med en mer försumbar inverkan, är att delvis stödda callables inte längre är tillåtna.
Dessa callables kallas delvis stödda eftersom du inte kan interagera med dem direkt via $callable(). Du kan endast komma åt dem med funktionen call_user_func($callable). Förteckningen över sådana callables är inte lång:
"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]Från och med PHP 8.2 och framåt så kommer alla försök att anropa sådana callables — t.ex. via funktionerna call_user_func() eller array_map() — att ge en avskrivnings-varning.
I den ursprungliga RFC:n så finns en solid motivering för denna avskrivning:
Med undantag för de två sista fallen är alla dessa callables kontextberoende. Den metod som
"self::method"hänvisar till beror på vilken klass som anropet eller kontrollen av anropbarhet utförs ifrån. I praktiken gäller detta vanligtvis även för de två sista fallen, när de används i form av[new Foo, "parent::method"].Att minska kontextberoendet för callables är det sekundära målet för detta RFC. Efter detta RFC är det enda scope-beroende som återstår synlighet av metoder:
"Foo::bar"kan vara synlig i ett scope, men inte i ett annat. Om callables skulle begränsas till offentliga metoder i framtiden (medan privata metoder skulle behöva använda förstklassiga callables ellerClosure::fromCallable()för att bli scope-oberoende), skulle callable-typen bli väldefinierad och kunna användas som en egenskapstyp. Ändringar av synlighetshanteringen föreslås dock inte som en del av detta RFC.
I enlighet med ursprungligt RFC så kommer funktionen is_callable() och typen callable att fortsätta att acceptera dessa callables som undantag. Men bara tills stödet för dem tas bort helt och hållet från och med PHP 9.0.
För att undvika förvirring utökades tillämpningsområdet för detta avskrivningsmeddelande med ett nytt RFC — det omfattar nu även dessa undantag.
Det är bra att se att PHP rör sig mot att ha en väldefinieradcallable-typ.
Avskaffa funktionerna #utf8_encode() och utf8_decode()
PHP:s inbyggda funktioner utf8_encode() och utf8_decode() konverterar strängar som är kodade i ISO-8859-1 (”Latin 1”) till och från UTF-8.
Deras namn antyder dock en mer allmän användning än vad deras implementering tillåter. Kodningen ”Latin 1” förväxlas ofta med andra kodningar som ”Windows Code Page 1252.”
Du ser dessutom vanligtvis Mojibake när dessa funktioner inte kan konvertera en sträng korrekt. Avsaknaden av felmeddelanden innebär även att det är svårt att upptäcka dem, särskilt i ett hav av annars läsbar text.
PHP 8.2 avvecklar både funktionerna #utf8_encode() och utf8_decode(). Om du anropar dem kommer du att möta dessa avskrivningsmeddelanden:
Deprecated: Function utf8_encode() is deprecated
Deprecated: Function utf8_decode() is deprecatedRFC föreslår att du istället använder PHP:s stödda tillägg som mbstring, iconv och intl.
Förutse ${} Sträng Interpolation
PHP tillåter inbäddning av variabler i strängar med dubbla citattecken (") och heredoc (<<<) på flera olika sätt:
- Direkt inbäddning av variabler —
“$foo” - Med hakparenteser utanför variabeln —
“{$foo}” - Med hakparenteser efter dollartecknet —
“${foo}” - Variabelvariabler —
“${expr}”— motsvarar att använda(string) ${expr}
De två första sätten har sina för- och nackdelar, medan de två sistnämnda har en komplex och motstridig syntax. I PHP 8.2 är de två sista sätten för interpolation av strängar överspelade.
Du bör undvika att interpolera strängar på detta sätt framöver:
"Hello, ${world}!";
Deprecated: Using ${} in strings is deprecated
"Hello, ${(world)}!";
Deprecated: Using ${} (variable variables) in strings is deprecatedFrån och med PHP 9.0 så kommer dessa avskrivningar att uppgraderas till att kasta ett undantagsfel.
Förutse mbstring-funktioner för Base64/QPrint/Uuencode/HTML-enheter
PHP:s mbstring-funktioner (multi-byte string) hjälper oss att arbeta med Unicode, HTML-enheter och andra äldre textkodningar.
Base64, Uuencode och QPrint är dock inte textkodningar och är fortfarande en del av dessa funktioner — främst av äldre skäl. PHP innehåller även separata implementeringar av dessa kodningar.
När det gäller HTML-enheter så har PHP inbyggda funktioner – htmlspecialchars() och htmlentities() — för att hantera dessa bättre. Till skillnad från mbstring konverterar dessa funktioner exempelvis även <. >, och &-tecken till HTML-enheter.
Dessutom förbättrar PHP ständigt sina inbyggda funktioner — precis som PHP 8.1 med HTML-kodnings- och avkodningsfunktioner.
Så med allt detta i åtanke avvecklar PHP 8.2 användningen av mbstring för dessa kodningar (etiketterna är inte skiftlägeskänsliga):
- BASE64
- UUENCODE
- HTML-ENTITIES
- html (alias för HTML-ENTITIES)
- Citat och utskrift
- qprint
Från och med PHP 8.2 och framåt så kommer användningen av mbstring för att koda/avkoda något av ovanstående att ge upphov till ett meddelande om avveckling. PHP 9.0 kommer att ta bort stödet för mbstring för dessa kodningar helt och hållet.
Andra mindre ändringar i PHP 8.2
Slutligen kan vi diskutera PHP 8.2:s mindre förändringar, inklusive borttagna egenskaper och funktioner.
Borttaget stöd för libmysql från mysqli
Från och med nu så tillåter PHP att både mysqli – och PDO_mysql-drivrutiner byggs mot mysqlnd– och libmysql-biblioteken. Den standardiserade och rekommenderade drivrutinen sedan PHP 5.4 har dock varit mysqlnd.
Båda dessa drivrutiner har många fördelar och nackdelar. Att ta bort stödet för en av dem — helst ta bort libmysql eftersom den inte är standard – kommer dock att förenkla PHP:s kod och enhetstester.
För att argumentera för denna fördel listar RFC många fördelar med mysqlnd:
- Det ingår i PHP
- Den använder PHP:s minneshantering för att övervaka minnesanvändning och
förbättra prestandan - Ger funktioner för livskvalitet (t.ex.
get_result()) - Återger numeriska värden med hjälp av PHP:s inhemska typer
- Dess funktionalitet är inte beroende av det externa biblioteket
- Valfri funktionalitet för plugins
- Stödjer asynkrona frågor
RFC listar även några fördelar med libmysql, bland annat:
- Det är möjligt med automatisk återkoppling (
mysqlndstöder inte denna funktionalitet avsiktligt eftersom den lätt kan utnyttjas) - LDAP- och SASL-autentiseringslägen (
mysqlndkan snart lägga till denna funktion)
I RFC anges dessutom många nackdelar med libmysql — inkompatibilitet med PHP:s minnesmodell, många misslyckade tester, minnesläckor, olika funktioner mellan olika versioner osv.
Med allt detta i åtanke tog PHP 8.2 bort stödet för att bygga mysqli mot libmysql.
Om du vill lägga till någon funktionalitet som endast är tillgänglig med libmysql så måste du uttryckligen lägga till den i mysqlnd som en funktionsbegäran. Du kan inte heller lägga till auto-reconnect.
Lokaloberoende fallkonvertering
Före PHP 8.0 ärvdes PHP:s lokalitet från systemmiljön. Detta kunde dock orsaka problem i vissa fall.
Om du ställer in ditt språk när du installerar Linux så kommer detta att ställa in lämpligt språk för användargränssnittet för dess inbyggda kommandon. Men det ändrar även oväntat hur C-bibliotekets stränghanteringsfunktionalitet fungerar.
Om du exempelvis valde språket ”turkiska” eller ”kazakiska” när du installerade Linux, så kommer du att upptäcka att om du anropar toupper('i') för att få fram dess versalekvivalent, kommer du att få fram det streckade stora I:et (U+0130, İ).
PHP 8.0 stoppade denna anomali genom att ställa in standardlokalspråket till ”C”, såvida inte användaren uttryckligen ändrar det via setlocale().
PHP 8.2 går ännu längre genom att avlägsna lokal känslighet från storleksomvandlingar. Detta RFC ändrar främst strtolower(), strtoupper() och relaterade funktioner. Läs RFC:n för en lista över alla berörda funktioner.
Om du vill använda lokalanpassad konvertering av versaler så kan du använda mb_strtolower() som ett alternativ.
Förbättring av slumpmässiga tillägg
PHP planerar att se över sin slumpfunktionalitet.
För närvarande är PHP:s slumpfunktionalitet starkt beroende av Mersenne Twister-tillståndet. Detta tillstånd lagras dock implicit i PHP:s globala område — det finns inget sätt för en användare att komma åt det. Att lägga till randomiseringsfunktioner mellan det första utsättningsstadiet och den avsedda användningen skulle bryta koden.
Att underhålla en sådan kod kan bli ännu mer komplicerat när din kod använder externa paket.
PHP:s nuvarande slumpfunktionalitet kan alltså inte reproducera slumpmässiga värden på ett konsekvent sätt. Den misslyckas till och med med empiriska statistiska tester av enhetliga slumptalsgeneratorer, som TestU01:s Crush och BigCrush. Mersenne Twisters 32-bitarsbegränsning förvärrar detta ytterligare.
Därför rekommenderas inte användningen av PHP:s inbyggda funktioner — shuffle(), str_shuffle(), array_rand() — om du behöver kryptografiskt säkra slumpmässiga tal. I sådana fall måste du implementera en ny funktion med hjälp av random_int() eller liknande funktioner.
Flera problem med detta RFC togs dock upp efter att omröstningen hade börjat. Detta bakslag tvingade PHP-teamet att notera alla problem i ett separat RFC, med ett skapat röstningsalternativ för varje problem. De kommer att besluta om att gå vidare först när de har nått samförstånd.
Ytterligare RFC:er i PHP 8.2
PHP 8.2 innehåller även många nya funktioner och mindre ändringar. Vi nämner dem nedan med länkar till ytterligare resurser:
- Ny funktion på
curl_upkeep: PHP 8.2 lägger till den här nya funktionen till sitt Curl-tillägg. Den anropar funktionencurl_easy_upkeep()i libcurl, det underliggande C-biblioteket som PHP:s Curl-tillägg använder. - Ny funktion
ini_parse_quantity: PHP INI-direktiv accepterar datastorlekar med ett multiplikatorsuffix. Du kan exempelvis skriva 25 megabyte som25M, eller 42 gigabyte som42G. Dessa suffix är vanliga i PHP INI-filer men är ovanliga på andra ställen. Den här nya funktionen analyserar PHP INI-värdena och returnerar deras datastorlek i byte. - Ny funktion
memory_reset_peak_usage: Den här funktionen återställer den högsta minnesanvändningen som returneras av funktionenmemory_get_peak_usage. Det kan vara praktiskt när du kör samma åtgärd flera gånger och vill registrera varje körnings högsta minnesanvändning. - Stöd för modifieringen no-capture (
/n) ipreg_*-funktioner: I regex anger metatecknen()en fångstgrupp. Det betyder att alla träffar för uttrycket inom parentesen returneras. PHP 8.2 lägger till en no-capture-modifier (/n) för att stoppa detta beteende. - Gör så att
iterator_*()-familjen accepterar alla iterables: För närvarande accepterar PHP:siterator_*()-familj endastTraversables(dvs. inga vanliga matriser tillåts). Detta är onödigt begränsande, och detta RFC åtgärdar detta.
Sammanfattning
PHP 8.2 bygger vidare på de enorma förbättringarna i PHP 8.0 och PHP 8.1, vilket inte är någon lätt uppgift. Vi tycker att de mest spännande funktionerna i PHP 8.2 är de nya fristående typerna, de skrivskyddade egenskaperna och de många prestandaförbättringarna.
Vi kan inte vänta på att jämföra PHP 8.2 med olika PHP-ramverk och CMS.
Se till att bokmärka det här blogginlägget för framtida referens.
Vilka funktioner i PHP 8.2 är dina favoriter? Vilka avskrivningar är de funktioner som du uppskattar minst? Dela gärna med dig av dina tankar till vårt community i kommentarerna!
Lämna ett svar