PHP 8.2'deki Yenilikler — Yeni Özellikler, Kullanımdan Kaldırmalar, Değişiklikler ve Daha Fazlası

PHP 8.2, PHP 8.0 ve PHP 8.1 tarafından ortaya konan yenilenmiş temel üzerine inşa edilmiştir. 24 Kasım 2022'de piyasaya sürülmesi planlanıyor.

Bu makale PHP 8.2'deki yenilikleri ayrıntılı olarak ele alacak - yeni özelliklerinden ve iyileştirmelerinden kullanımdan kaldırmalara ve küçük değişikliklere kadar hepsini inceleyeceğiz.

PHP 8.2, 19 Temmuz 2022'de özellik dondurmasına girdiğinden, bu listeye önemli bir ekleme bekleyemezsiniz.

Heyecanlı? Biz de.

Hadi başlayalım!

PHP 8.2'deki Yeni Özellikler ve İyileştirmeler

En son PHP 8.2 özelliklerini keşfederek başlayalım. Oldukça kapsamlı bir liste:

Yeni readonly Sınıflar

PHP 8.1, sınıf özellikleri için readonly özelliği tanıttı. Şimdi, PHP 8.2, tüm sınıfı readonly olarak bildirmek için destek ekliyor.

Bir sınıfı readonly olarak bildirirseniz, tüm özellikleri readonly özelliğini otomatik olarak devralır. Bu nedenle, bir sınıfı readonly olarak bildirmek, her sınıf özelliğini readonly olarak bildirmekle aynıdır.

Örneğin, PHP 8.1 ile, tüm sınıf özelliklerini readonly olarak bildirmek için bu sıkıcı kodu yazmanız gerekiyordu:

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

Aynı şeyi daha birçok özellik ile hayal edin. Şimdi, PHP 8.2 ile şunu yazabilirsiniz:

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

Ayrıca özet veya son sınıfları readonly olarak bildirebilirsiniz. Burada anahtar kelimelerin sırası önemli değildir.

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

Ayrıca, hiçbir özelliği olmayan readonly bir sınıf bildirebilirsiniz. Etkili bir şekilde bu, dinamik özellikleri engellerken alt sınıfların readonly özelliklerini açıkça bildirmelerine izin verir.

Sırada, readonly sınıflar yalnızca yazılan özellikleri içerebilir - tek tek salt okunur özellikleri bildirmek için aynı kural.

Kesin olarak yazılan bir özellik bildiremiyorsanız, mixed tür özelliğini kullanabilirsiniz.

Yazılan bir özellik olmadan readonly bir sınıf bildirmeye çalışmak, Önemli bir hataya neden olur:

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

Ayrıca, belirli PHP özellikleri için readonly olarak bildiremezsiniz:

• Numaralandırmalar (herhangi bir özellik içeremeyecekleri için)
• Özellikler
• Arayüzler

Bu özelliklerden herhangi birinin readonly olarak bildirilmeye çalışılması, bir Ayrıştırma hatasıyla sonuçlanacaktır.

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

Tüm PHP anahtar sözcüklerinde olduğu gibi, readonly anahtar sözcük de büyük/küçük harf duyarlı değildir.

PHP 8.2 ayrıca dinamik özellikleri de kullanımdan kaldırır (daha sonra anlatacağız). Ancak dinamik özelliklerin bir sınıfa eklenmesini engelleyemezsiniz. Ancak, readonly bir sınıf için bunu yapmak yalnızca Önemli Hataya neden olur.

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

Bağımsız Türler olarak true , false ve null 'a izin verin

PHP zaten int , string ve bool gibi skaler türleri içerir. Bu, PHP 8.0'da birleşim türlerinin eklenmesiyle genişletildi ve değerlerin farklı türlerde olmasına izin verildi. Aynı RFC, bir birlik türünün parçası olarak false ve null kullanılmasına da izin verdi - yine de bağımsız türler olarak izin verilmedi.

false veya null veya bağımsız türler olarak - bir birlik türünün parçası olmadan - bildirmeyi denediyseniz, bu önemli bir hatayla sonuçlandı.

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

Bu senaryodan kaçınmak için PHP 8.2, bağımsız türler olarak false ve null kullanımı için destek ekliyor. Bu ekleme ile PHP'nin tip sistemi daha anlamlı ve eksiksizdir. Artık dönüş, parametre ve özellik türlerini tam olarak bildirebilirsiniz.

Ayrıca, PHP hala false türün doğal bir karşılığı gibi görünen true bir tür içermez. PHP 8.2 bunu düzeltir ve true tür için de destek ekler. Tıpkı false tipinin nasıl davrandığı gibi, zorlamaya izin vermez.

Hem true hem de false türleri, temelde PHP'nin bool türünün birleşim türüdür. Fazlalıktan kaçınmak için, bu üç türü bir birleşim türünde birlikte bildiremezsiniz. Bunu yapmak, derleme zamanında önemli bir hataya neden olur.

Ayrık Normal Form (DNF) Tipleri

Ayrık Normal Form (DNF), boolean ifadeleri düzenlemenin standart bir yoludur. Bağlaçların ayrılmasından oluşur - boole terimleriyle, bu VE'lerin bir VEYA'sıdır .

DNF'yi tür bildirimlerine uygulamak, ayrıştırıcının işleyebileceği birleştirilmiş Birlik ve Kesişme türlerini yazmak için standart bir yol sağlar. PHP 8.2'nin yeni DNF türleri özelliği, doğru kullanıldığında basit ancak güçlüdür.

RFC aşağıdaki örneği verir. Aşağıdaki arabirim ve sınıf tanımlarının zaten mevcut olduğunu varsayar:

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

DNF türleri ile, aşağıdaki gibi özellikler, parametreler ve dönüş değerleri için tür bildirimleri gerçekleştirebilirsiniz:

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

Bazı durumlarda, özellikler DNF formlarında olmayabilir. Bunları bu şekilde bildirmek, bir ayrıştırma hatasıyla sonuçlanacaktır. Ancak bunları her zaman şu şekilde yeniden yazabilirsiniz:

 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

Bir DNF türünün her segmentinin benzersiz olması gerektiğini unutmayın. Örneğin, iki OR ed segmenti mantıksal olarak aynı olduğundan (A&B)|(B&A) bildirimi geçersizdir.

Buna ek olarak, diğer segmentin katı alt kümeleri olan segmentlere de izin verilmez. Bunun nedeni, üst kümenin zaten alt kümenin tüm örneklerine sahip olması ve bu da DNF'yi kullanmayı gereksiz hale getirmesidir.

Arka İzlerde Hassas Parametreleri Redact

Hemen hemen tüm programlama dilleri gibi, PHP de kodun yürütülmesinin herhangi bir noktasında çağrı yığınının izlenmesine izin verir. Yığın izleme, hataları ve performans darboğazlarını düzeltmek için kodda hata ayıklamayı kolaylaştırır. WordPress siteleri için özel olarak tasarlanmış performans izleme aracımız olan Kinsta APM gibi araçların bel kemiğini oluşturur.

Yığın izleme gerçekleştirmek, programın yürütülmesini durdurmaz. Tipik olarak, yığın izlemelerinin çoğu arka planda çalışır ve gerekirse daha sonra incelenmek üzere sessizce günlüğe kaydedilir.

Ancak, bu ayrıntılı PHP yığın izlemelerinden bazıları, bunları üçüncü taraf hizmetlerle paylaşırsanız, genellikle hata günlüğü analizi, hata izleme vb. için bir dezavantaj olabilir. Bu yığın izleri, kullanıcı adları, parolalar ve ortam değişkenleri gibi hassas bilgileri içerebilir. .

Bu RFC teklifi böyle bir örnek verir:

Yaygın bir "suçlu", veritabanı parolasını bir kurucu parametresi olarak alan ve saf bir kurucu ve ayrı bir ->connect() yöntemi yerine hemen kurucu içindeki veritabanına bağlanmaya çalışan PDO'dur. Bu nedenle, veritabanı bağlantısı başarısız olduğunda, yığın izlemesi veritabanı parolasını içerecektir:

 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, bu tür hassas parametreleri yeni bir \SensitiveParameter özniteliği ile işaretlemenize olanak tanır. Hassas olarak işaretlenen herhangi bir parametre, geriye dönük izlemelerinizde listelenmeyecektir. Böylece, herhangi bir üçüncü taraf hizmet ile endişe duymadan paylaşabilirsiniz.

İşte tek bir hassas parametre ile basit bir örnek:

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

Geri izleme oluşturduğunuzda, \SensitiveParameter özniteliğine sahip herhangi bir parametre bir \SensitiveParameterValue nesnesiyle değiştirilir ve gerçek değeri hiçbir zaman izlemede saklanmaz. SensitiveParameterValue nesnesi, herhangi bir nedenle ihtiyacınız varsa, gerçek parametre değerini kapsüller.

Yeni mysqli_execute_query İşlevi ve mysqli::execute_query Yöntemi

Yalnızca parametreli bir MySQLi sorgusu çalıştırmak için tehlikeli şekilde kaçan kullanıcı değerleriyle mysqli_query() işlevini hiç kullandınız mı?

PHP 8.2, yeni mysqli_execute_query($sql, $params) işlevi ve mysqli::execute_query yöntemiyle parametreli MySQLi sorgularını çalıştırmayı kolaylaştırır.

Esasen, bu yeni işlev mysqli_prepare() , mysqli_execute() ve mysqli_stmt_get_result() işlevlerinin bir birleşimidir. Bununla birlikte, MySQLi sorgusu hazırlanacak, bağlanacak (eğer herhangi bir parametre iletirseniz) ve fonksiyonun kendisinde yürütülecektir. Sorgu başarılı bir şekilde çalışırsa, bir mysqli_result nesnesi döndürür. Başarısız olursa, false .

RFC önerisi basit ama güçlü bir örnek verir:

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

const İfadelerinde enum Özelliklerini getir

Bu RFC, ->/?-> operatörünün const ifadelerinde enum özelliklerini getirmesine izin vermeyi önerir.

Bu yeni özelliğin temel nedeni, dizi tuşları gibi bazı yerlerde enum nesnelerini kullanamamanızdır. Böyle bir durumda, sadece kullanmak için enum vakasının değerini tekrarlamanız gerekir.

enum nesnelerine izin verilmeyen yerlerde enum özelliklerinin getirilmesine izin vermek bu yordamı basitleştirebilir.

Bu, aşağıdaki kodun artık geçerli olduğu anlamına gelir:

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

Ve sadece güvende olmak için, bu RFC ayrıca nullsafe operatörü ?-> için destek içerir.

Özelliklerde Sabitlere İzin Ver

PHP, Özellikler adlı kodu yeniden kullanmanın bir yolunu içerir. Sınıflar arasında kodun yeniden kullanımı için harikadırlar.

Şu anda, Özellikler yalnızca yöntem ve özelliklerin tanımlanmasına izin verir, ancak sabitlere izin vermez. Bu, Özelliğin kendi içinde bir Özellik tarafından beklenen değişmezleri tanımlayamayacağınız anlamına gelir. Bu sınırlamayı aşmak için, oluşturma sınıfında veya oluşturma sınıfı tarafından uygulanan bir arabirimde sabitler tanımlamanız gerekir.

Bu RFC, Özellikler'de sabitlerin tanımlanmasına izin vermeyi önerir. Bu sabitler, tıpkı sınıf sabitlerini tanımladığınız gibi tanımlanabilir. Doğrudan RFC'den alınan bu örnek, kullanımının havasını temizler:

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

Özellik sabitleri de, bir Özelliğin özellik ve yöntem tanımlarıyla aynı şekilde, oluşturma sınıfının tanımıyla birleştirilir. Ayrıca, Niteliklerin özellikleriyle benzer kısıtlamalara sahiptirler. RFC'de belirtildiği gibi, bu teklif - iyi bir başlangıç ​​olsa da - özelliğin detaylandırılması için daha fazla çalışmaya ihtiyaç duyuyor.

PHP 8.2'deki kullanımdan kaldırmalar

Artık PHP 8.2'deki tüm kullanımdan kaldırmaları keşfetmeye geçebiliriz. Bu liste, yeni özellikleri kadar büyük değil:

Dinamik Özellikleri (ve Yeni #[AllowDynamicProperties] Özelliğini) kullanımdan kaldırın

PHP 8.1'e kadar, PHP'de bildirilmemiş sınıf özelliklerini dinamik olarak ayarlayabilir ve alabilirsiniz. Örneğin:

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

Burada, Post sınıfı bir name özelliği bildirmez. Ancak PHP dinamik özelliklere izin verdiği için, onu sınıf bildiriminin dışında ayarlayabilirsiniz. Bu onun en büyük - ve muhtemelen tek - avantajı.

Dinamik özellikler, kodunuzda beklenmeyen hataların ve davranışların ortaya çıkmasına izin verir. Örneğin, sınıfın dışında bir sınıf özelliği bildirirken herhangi bir hata yaparsanız, özellikle o sınıf içindeki herhangi bir hatayı ayıklarken, izini kaybetmek kolaydır.

PHP 8.2'den itibaren dinamik özellikler kullanımdan kaldırılmıştır. Bildirilmemiş bir sınıf özelliğine bir değer ayarlamak, özellik ilk kez ayarlandığında bir kullanımdan kaldırma bildirimi yayacaktır.

 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;

Ancak, PHP 9.0'dan itibaren, aynı ayarın yapılması ErrorException hatası verecektir.

Kodunuz dinamik özelliklerle doluysa ve çok sayıda PHP kodu varsa ve PHP 8.2'ye yükselttikten sonra bu kullanımdan kaldırma bildirimlerini durdurmak istiyorsanız, dinamik özelliklere izin vermek için PHP 8.2'nin yeni #[AllowDynamicProperties] özniteliğini kullanabilirsiniz. sınıflardaki özellikler.

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

RFC'ye göre, #[AllowDynamicProperties] olarak işaretlenen sınıflar ve bunların alt sınıfları, kullanımdan kaldırılmadan veya kaldırılmadan dinamik özellikleri kullanmaya devam edebilir.

Ayrıca PHP 8.2'de, #[AllowDynamicProperties] olarak işaretlenmiş tek paketlenmiş sınıfın stdClass olduğunu da unutmamalısınız. Ayrıca, __get() veya __set() PHP sihirli yöntemleri aracılığıyla erişilen özellikler dinamik özellikler olarak kabul edilmez, bu nedenle bir kullanımdan kaldırma bildirimi atmazlar.

Kısmen Desteklenen Çağrıları Kullanımdan Kaldırın

Daha önemsiz bir etkiye sahip olsa da, başka bir PHP 8.2 değişikliği, kısmen desteklenen çağrılabilirleri kullanımdan kaldırmaktır.

Bu çağrılabilirler, kısmen desteklenir, çünkü onlarla doğrudan $callable() aracılığıyla etkileşim kuramazsınız. Onlara yalnızca call_user_func($callable) işleviyle ulaşabilirsiniz. Bu tür çağrıların listesi uzun değildir:

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

PHP 8.2'den itibaren, call_user_func() veya array_map() işlevleri aracılığıyla bu tür çağrılabilirleri çağırma girişimleri, bir kullanımdan kaldırma uyarısı verecektir.

Orijinal RFC, bu kullanımdan kaldırmanın arkasında sağlam bir gerekçe sunar:

Son iki durum dışında, bu çağrılabilirlerin tümü bağlama bağımlıdır. "self::method" ifadesinin atıfta bulunduğu yöntem, çağrının veya çağrılabilirlik kontrolünün hangi sınıftan gerçekleştirildiğine bağlıdır. Pratikte, bu genellikle [new Foo, "parent::method"] biçiminde kullanıldığında son iki durum için de geçerlidir.

Çağrılabilirlerin bağlam bağımlılığını azaltmak, bu RFC'nin ikincil amacıdır. Bu RFC'den sonra, geriye kalan tek kapsam bağımlılığı yöntem görünürlüğüdür: "Foo::bar" bir kapsamda görünebilir, ancak diğerinde görünmeyebilir. Çağırılabilirler gelecekte genel yöntemlerle sınırlandırılacaksa (özel yöntemlerin kapsamdan bağımsız hale getirilmesi için birinci sınıf çağrılabilirleri veya Closure::fromCallable() kullanması gerekirken), çağrılabilir tür iyi tanımlanmış olur ve bir özellik türü olarak kullanılabilir. Ancak, görünürlük işlemede değişiklikler bu RFC'nin bir parçası olarak önerilmez .

Orijinal RFC'ye göre, is_callable() işlevi ve callable tür, bu çağrılabilirleri istisna olarak kabul etmeye devam edecektir. Ancak yalnızca onlar için destek PHP 9.0'dan tamamen kaldırılana kadar.

Karışıklığı önlemek için bu kullanımdan kaldırma bildirimi kapsamı yeni bir RFC ile genişletildi - artık bu istisnaları içeriyor.

PHP'nin iyi tanımlanmış bir callable türe doğru ilerlediğini görmek güzel.

#utf8_encode() ve utf8_decode() İşlevlerini Kullanımdan Kaldırın

PHP'nin yerleşik işlevleri utf8_encode() ve utf8_decode() , ISO-8859-1'de (“Latin 1”) kodlanmış dizeleri UTF-8'e ve UTF-8'den dönüştürür.

Ancak adları, uygulamalarının izin verdiğinden daha genel bir kullanım önerir. "Latin 1" kodlaması, genellikle "Windows Code Page 1252" gibi diğer kodlamalarla karıştırılır.

Ayrıca, bu işlevler herhangi bir dizeyi düzgün bir şekilde dönüştüremediğinde genellikle Mojibake'i görürsünüz. Hata mesajlarının olmaması, özellikle okunaklı bir metin denizi içinde, onları tespit etmenin zor olduğu anlamına gelir.

PHP 8.2, hem #utf8_encode() hem de utf8_decode() işlevlerini kullanımdan kaldırır. Bunları çağırırsanız, şu kullanımdan kaldırma bildirimlerini görürsünüz:

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

RFC, bunun yerine PHP'nin mbstring , iconv ve intl gibi desteklenen uzantılarının kullanılmasını önerir.

${} Dize İnterpolasyonunu Kullanımdan Kaldırın

PHP, değişkenleri çift tırnak ( " ) ve heredoc ( <<< ) içeren dizelere çeşitli şekillerde yerleştirmeye izin verir:

1. Değişkenleri doğrudan gömme — “$foo”
2. “{$foo}” değişkeninin dışında parantezler ile
3. Dolar işaretinden sonra kaşlı ayraçlarla — “${foo}”
4. Değişken değişkenler — “${expr}” — (string) ${expr} kullanımına eşdeğer

İlk iki yolun artıları ve eksileri vardır, son ikisi ise karmaşık ve çelişkili sözdizimine sahiptir. PHP 8.2, dize enterpolasyonunun son iki yolunu kullanımdan kaldırır.

Bu şekilde ileriye doğru enterpolasyon yapan dizelerden uzak durmalısınız:

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

PHP 9.0'dan başlayarak, bu kullanımdan kaldırmalar bir istisna hatası verecek şekilde yükseltilecektir.

Base64/QPrint/Uuencode/HTML Varlıkları için mbstring İşlevlerini Kullanımdan Kaldırın

PHP'nin mbstring (çok baytlı dize) işlevleri, Unicode, HTML varlıkları ve diğer eski metin kodlamalarıyla çalışmamıza yardımcı olur.

Ancak Base64, Uuencode ve QPrint, metin kodlamaları değildir ve esas olarak eski nedenlerden dolayı hala bu işlevlerin bir parçasıdır. PHP ayrıca bu kodlamaların ayrı uygulamalarını da içerir.

HTML varlıklarına gelince, PHP, bunlarla daha iyi başa çıkmak için yerleşik işlevlere ( htmlspecialchars() ve htmlentities() sahiptir. Örneğin, mbstring'den farklı olarak, bu işlevler aynı zamanda < yi de dönüştürecektir. > , ve & karakterleri HTML varlıklarına.

Ayrıca PHP, yerleşik işlevlerini her zaman geliştiriyor - tıpkı HTML kodlama ve kod çözme işlevlerine sahip PHP 8.1 gibi.

Bu nedenle, tüm bunları akılda tutarak, PHP 8.2 bu kodlamalar için mbstring kullanımını kullanımdan kaldırıyor (etiketler büyük/küçük harfe duyarlı değildir):

• BASE64
• UUENKODU
• HTML-ENTITIES
• html (HTML-ENTITIES takma adı)
• Alıntı-Yazdırılabilir
• qprint (Alıntılı-Yazdırılabilir'in diğer adı)

PHP 8.2'den itibaren, yukarıdakilerden herhangi birini kodlamak/kodunu çözmek için mbstring kullanmak bir kullanımdan kaldırma bildirimi verecektir. PHP 9.0, bu kodlamalar için mbstring desteğini tamamen kaldıracaktır.

PHP 8.2'deki Diğer Küçük Değişiklikler

Son olarak, PHP 8.2'nin kaldırılan özellikleri ve işlevleri de dahil olmak üzere küçük değişikliklerini tartışabiliriz.

Mysqli'den libmysql Desteğini Kaldır

Şu an itibariyle PHP, hem mysqli hem de PDO_mysql sürücülerinin mysqlnd ve libmysql kitaplıklarına karşı derleme yapmasına izin veriyor. Ancak, PHP 5.4'ten bu yana varsayılan ve önerilen sürücü mysqlnd olmuştur.

Bu sürücülerin her ikisinin de birçok avantajı ve dezavantajı vardır. Bununla birlikte, bunlardan birinin desteğinin kaldırılması - ideal olarak, varsayılan olmadığı için libmysql kaldırılması - PHP'nin kod ve birim testlerini basitleştirecektir.

Bu iyilik için bir argüman yapmak için RFC, mysqlnd birçok avantajını listeler:

• PHP ile paketlenmiştir
• Bellek kullanımını izlemek için PHP bellek yönetimini kullanır ve
  performans geliştirme
• Yaşam kalitesi işlevleri sağlar (örneğin get_result() )
• PHP yerel türlerini kullanarak sayısal değerler döndürür
• İşlevselliği harici kütüphaneye bağlı değildir
• İsteğe bağlı eklenti işlevi
• Eşzamansız sorguları destekler

RFC ayrıca libmysql aşağıdakiler dahil bazı avantajlarını da listeler:

• Otomatik yeniden bağlanma mümkündür ( mysqlnd , kolayca yararlanılabileceği için bu işlevi kasıtlı olarak desteklemez)
• LDAP ve SASL kimlik doğrulama modları ( mysqlnd yakında bu özelliği de ekleyebilir)

Ek olarak, RFC libmysql birçok dezavantajını listeler - PHP bellek modeliyle uyumsuzluk, birçok başarısız test, bellek sızıntısı, sürümler arasında farklı işlevler vb.

Tüm bunları akılda tutarak, PHP 8.2, libmysql karşı mysqli oluşturma desteğini kaldırdı.

Yalnızca libmysql ile kullanılabilen herhangi bir işlevsellik eklemek istiyorsanız, bunu bir özellik isteği olarak açıkça mysqlnd eklemeniz gerekir. Ayrıca, otomatik yeniden bağlanma ekleyemezsiniz.

Yerel Ayardan Bağımsız Vaka Dönüştürme

PHP 8.0'dan önce, PHP'nin yerel ayarı sistem ortamından devralınırdı. Ancak bu, bazı uç durumlarda bir soruna neden olabilir.

Linux'u kurarken dilinizi ayarlamak, yerleşik komutlar için uygun kullanıcı arabirimi dilini ayarlayacaktır. Ancak, beklenmedik bir şekilde C kitaplığının dize işleme işlevinin çalışma şeklini de değiştirir.

Örneğin, Linux'u kurarken “Türkçe” veya “Kazakça” dilini seçtiyseniz, büyük harf karşılığını almak için toupper('i') çağrısının noktalı büyük harf I (U+0130, I ) alacağını göreceksiniz.

PHP 8.0, kullanıcı bunu setlocale() aracılığıyla açıkça değiştirmedikçe, varsayılan yerel ayarı “C” olarak ayarlayarak bu anormalliği durdurdu.

PHP 8.2, büyük/küçük harf dönüşümlerinden yerel ayar hassasiyetini kaldırarak daha da ileri gider. Bu RFC öncelikle strtolower() , strtoupper() ve ilgili işlevleri değiştirir. Etkilenen tüm işlevlerin listesi için RFC'yi okuyun.

Alternatif olarak, yerelleştirilmiş büyük/küçük harf dönüşümü kullanmak istiyorsanız, mb_strtolower() kullanabilirsiniz.

Rastgele Uzantı İyileştirmesi

PHP, rastgele işlevselliğini elden geçirmeyi planlıyor.

Şu an itibariyle, PHP'nin rastgele işlevselliği büyük ölçüde Mersenne Twister durumuna bağlıdır. Ancak, bu durum PHP'nin global alanında örtük olarak saklanır - bir kullanıcının buna erişmesinin hiçbir yolu yoktur. İlk tohumlama aşaması ile amaçlanan kullanım arasına rasgeleleştirme işlevleri eklemek kodu bozar.

Kodunuz harici paketler kullandığında, bu tür bir kodun bakımı daha da karmaşık olabilir.

Bu nedenle, PHP'nin mevcut rastgele işlevi, rastgele değerleri tutarlı bir şekilde yeniden üretemez. TestU01'in Crush ve BigCrush gibi tek tip rasgele sayı üreteçlerinin deneysel istatistiksel testlerinde bile başarısız oluyor. Mersenne Twister'ın 32-bit sınırlaması bunu daha da şiddetlendiriyor.

Bu nedenle, kriptografik olarak güvenli rastgele sayılara ihtiyacınız varsa, PHP'nin yerleşik işlevlerini — shuffle() , str_shuffle() , array_rand() — kullanmanız önerilmez. Bu gibi durumlarda, random_int() veya benzer işlevleri kullanarak yeni bir işlev uygulamanız gerekir.

Ancak, oylama başladıktan sonra bu RFC ile ilgili bazı sorunlar gündeme geldi. Bu aksilik, PHP ekibini tüm sorunları ayrı bir RFC'ye not etmeye zorladı ve her sayı için bir oylama seçeneği oluşturuldu. Ancak bir fikir birliğine vardıktan sonra daha fazla ilerlemeye karar verecekler.

PHP 8.2'deki Ek RFC'ler

PHP 8.2 ayrıca birçok yeni işlev ve küçük değişiklik içerir. Ek kaynaklara bağlantılarla birlikte bunlardan aşağıda bahsedeceğiz:

1. Yeni curl_upkeep işlevi: PHP 8.2, bu yeni işlevi Curl uzantısına ekler. PHP Curl uzantısının kullandığı temel C kitaplığı olan libcurl'deki curl_easy_upkeep() işlevini çağırır.
2. Yeni ini_parse_quantity işlevi: PHP INI yönergeleri, çarpan sonekiyle veri boyutlarını kabul eder. Örneğin, 25 Megabyte'ı 25M olarak veya 42 Gigabyte'ı sadece 42G olarak yazabilirsiniz. Bu son ekler PHP INI dosyalarında yaygındır ancak başka yerlerde yaygın değildir. Bu yeni işlev PHP INI değerlerini ayrıştırır ve veri boyutlarını bayt olarak döndürür.
3. Yeni memory_reset_peak_usage işlevi: Bu işlev, memory_get_peak_usage işlevi tarafından döndürülen en yüksek bellek kullanımını sıfırlar. Aynı eylemi birden çok kez çalıştırdığınızda ve her çalıştırmanın en yüksek bellek kullanımını kaydetmek istediğinizde kullanışlı olabilir.
4. preg_* işlevlerinde no-capture değiştiricisi ( /n ) desteği: Normal ifadede, () meta karakterleri bir yakalama grubunu belirtir. Bu, parantez içindeki ifade için tüm eşleşmelerin döndürüldüğü anlamına gelir. PHP 8.2, bu davranışı durdurmak için yakalamasız bir değiştirici ( /n ) ekler.
5. iterator_*() ailesinin tüm yinelenebilirleri kabul etmesini sağlayın: Şu andan itibaren PHP'nin iterator_*() ailesi yalnızca \Traversables kabul eder (yani düz dizilere izin verilmez). Gereksiz yere sınırlayıcıdır ve bu RFC bunu düzeltir.

Özet

PHP 8.2, PHP 8.0 ve PHP 8.1'deki büyük iyileştirmeler üzerine kuruludur ve bu kolay bir başarı değildir. En heyecan verici PHP 8.2 özelliklerinin yeni bağımsız türleri, salt okunur özellikleri ve çok sayıda performans iyileştirmesi olduğunu düşünüyoruz.

PHP 8.2'yi çeşitli PHP çerçeveleri ve CMS'lerle karşılaştırmak için sabırsızlanıyoruz.

Gelecekte başvurmak üzere bu blog gönderisini favorilerinize eklediğinizden emin olun.

En sevdiğiniz PHP 8.2 özellikleri hangileri? En az sevdiğiniz kullanımdan kaldırmalar hangileri? Lütfen düşüncelerinizi yorumlarda topluluğumuzla paylaşın!