Apa yang Baru di PHP 8.2 — Fitur Baru, Penghentian, Perubahan, dan Lainnya

PHP 8.2 dibangun di atas basis baru yang ditetapkan oleh PHP 8.0 dan PHP 8.1. Rencananya akan dirilis pada 24 November 2022.

Artikel ini akan membahas apa yang baru di PHP 8.2 secara mendetail — mulai dari fitur dan peningkatan baru hingga penghentian dan perubahan kecil, kami akan membahas semuanya.

Saat PHP 8.2 memasuki pembekuan fitur pada 19 Juli 2022, Anda tidak dapat mengharapkan tambahan yang signifikan untuk daftar ini.

Bergairah? Kami juga.

Mari kita mulai!

Fitur dan Peningkatan Baru di PHP 8.2

Mari kita mulai dengan menjelajahi semua fitur PHP 8.2 terbaru. Ini daftar yang cukup luas:

Kelas baru readonly

PHP 8.1 memperkenalkan fitur readonly untuk properti kelas. Sekarang, PHP 8.2 menambahkan dukungan untuk mendeklarasikan seluruh kelas sebagai readonly .

Jika Anda mendeklarasikan sebuah kelas sebagai readonly , semua propertinya akan secara otomatis mewarisi fitur readonly . Dengan demikian, mendeklarasikan kelas readonly sama dengan mendeklarasikan setiap properti kelas sebagai readonly .

Misalnya, dengan PHP 8.1, Anda harus menulis kode yang membosankan ini untuk mendeklarasikan semua properti kelas sebagai readonly :

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

Bayangkan hal yang sama dengan lebih banyak properti. Sekarang, dengan PHP 8.2, Anda cukup menulis ini:

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

Anda juga dapat mendeklarasikan abstract atau final class sebagai readonly . Di sini, urutan kata kunci tidak masalah.

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

Anda juga dapat mendeklarasikan kelas readonly tanpa properti. Secara efektif, ini mencegah properti dinamis sambil tetap mengizinkan kelas anak untuk mendeklarasikan properti readonly mereka secara eksplisit.

Selanjutnya, kelas readonly hanya dapat berisi properti yang diketik — aturan yang sama untuk mendeklarasikan properti readonly individual.

Anda dapat menggunakan properti tipe mixed jika Anda tidak dapat mendeklarasikan properti yang diketik secara ketat.

Mencoba mendeklarasikan kelas readonly tanpa properti yang diketik akan menghasilkan kesalahan Fatal:

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

Selain itu, Anda tidak dapat mendeklarasikan readonly untuk fitur PHP tertentu:

• Enum (karena tidak dapat berisi properti apa pun)
• Sifat-sifat
• Antarmuka

Mencoba mendeklarasikan salah satu fitur ini sebagai hanya- readonly akan menghasilkan kesalahan Parse.

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

Seperti halnya untuk semua kata kunci PHP, kata kunci readonly tidak peka huruf besar-kecil.

PHP 8.2 juga tidak lagi menggunakan properti dinamis (lebih lanjut tentang itu nanti). Tetapi Anda tidak dapat mencegah properti dinamis ditambahkan ke kelas. Namun, melakukannya untuk kelas readonly hanya akan menghasilkan Kesalahan Fatal.

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

Izinkan true , false , dan null sebagai Standalone Types

PHP sudah menyertakan tipe skalar seperti int , string , dan bool . Itu diperluas di PHP 8.0 dengan penambahan tipe serikat, memungkinkan nilai menjadi tipe yang berbeda. RFC yang sama juga mengizinkan penggunaan false dan null sebagai bagian dari tipe gabungan — mereka tidak diizinkan sebagai tipe mandiri.

Jika Anda mencoba mendeklarasikan false atau null atau sebagai tipe mandiri — tanpa mereka menjadi bagian dari tipe gabungan — hal itu mengakibatkan kesalahan fatal.

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

Untuk menghindari skenario ini, PHP 8.2 menambahkan dukungan untuk menggunakan false dan null sebagai tipe mandiri. Dengan tambahan ini, sistem tipe PHP lebih ekspresif dan lengkap. Anda sekarang dapat mendeklarasikan tipe pengembalian, parameter, dan properti dengan tepat.

Selain itu, PHP masih belum menyertakan tipe true , yang tampaknya merupakan pasangan alami dari tipe false . PHP 8.2 memperbaikinya dan menambahkan dukungan untuk tipe yang true juga. Itu tidak mengizinkan paksaan, persis seperti bagaimana tipe false berperilaku.

Baik tipe true dan false pada dasarnya adalah tipe gabungan dari tipe bool PHP. Untuk menghindari redundansi, Anda tidak dapat mendeklarasikan ketiga tipe ini bersama-sama dalam tipe gabungan. Melakukannya akan menghasilkan kesalahan fatal waktu kompilasi.

Jenis Bentuk Normal Disjungtif (DNF)

Disjunctive Normal Form (DNF) adalah cara standar untuk mengatur ekspresi boolean. Ini terdiri dari disjungsi konjungsi — dalam istilah boolean, itu adalah OR dari ANDs .

Menerapkan DNF ke deklarasi tipe memungkinkan cara standar untuk menulis gabungan tipe Union dan Intersection yang dapat ditangani oleh parser. Fitur tipe DNF baru PHP 8.2 sederhana namun kuat jika digunakan dengan benar.

RFC memberikan contoh berikut. Ini mengasumsikan antarmuka dan definisi kelas berikut sudah ada:

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

Dengan tipe DNF, Anda dapat melakukan deklarasi tipe untuk properti, parameter, dan nilai pengembalian seperti:

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

Dalam beberapa kasus, properti mungkin tidak dalam bentuk DNF. Mendeklarasikan mereka seperti itu akan menghasilkan kesalahan parse. Tetapi Anda selalu dapat menulis ulang sebagai:

 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

Anda harus mencatat bahwa setiap segmen dari jenis DNF harus unik. Misalnya, mendeklarasikan (A&B)|(B&A) tidak valid karena dua segmen OR ed secara logis sama.

Selain itu, segmen yang merupakan subkumpulan ketat dari segmen lain juga tidak diizinkan. Itu karena superset sudah memiliki semua instance dari subset, sehingga penggunaan DNF menjadi mubazir.

Redact Parameter Sensitif di Back Traces

Seperti hampir semua bahasa pemrograman, PHP memungkinkan pelacakan tumpukan panggilannya pada titik mana pun dalam eksekusi kode. Pelacakan tumpukan memudahkan untuk men-debug kode untuk memperbaiki kesalahan dan kemacetan kinerja. Ini membentuk tulang punggung alat seperti Kinsta APM, alat pemantauan kinerja kami yang dirancang khusus untuk situs WordPress.

Melakukan pelacakan tumpukan tidak menghentikan eksekusi program. Biasanya, sebagian besar pelacakan tumpukan berjalan di latar belakang dan dicatat secara diam-diam — untuk pemeriksaan nanti jika diperlukan.

Namun, beberapa pelacakan tumpukan PHP yang terperinci ini dapat menjadi kelemahan jika Anda membagikannya dengan layanan pihak ketiga — biasanya untuk analisis log kesalahan, pelacakan kesalahan, dll. Pelacakan tumpukan ini dapat mencakup informasi sensitif seperti nama pengguna, kata sandi, dan variabel lingkungan. .

Proposal RFC ini memberikan satu contoh seperti:

Salah satu "pelanggar" umum adalah PDO yang mengambil kata sandi database sebagai parameter konstruktor dan segera mencoba untuk terhubung ke database di dalam konstruktor, alih-alih memiliki konstruktor murni dan metode ->connect() terpisah . Jadi ketika koneksi database gagal, jejak tumpukan akan menyertakan kata sandi database:

 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 memungkinkan Anda untuk menandai parameter sensitif tersebut dengan atribut \SensitiveParameter baru. Parameter apa pun yang ditandai sensitif tidak akan dicantumkan di jejak balik Anda. Dengan demikian, Anda dapat membagikannya tanpa khawatir dengan layanan pihak ketiga mana pun.

Berikut adalah contoh langsung dengan satu parameter sensitif:

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

Saat Anda membuat backtrace, parameter apa pun dengan atribut \SensitiveParameter akan diganti dengan objek \SensitiveParameterValue , dan nilai sebenarnya tidak akan pernah disimpan di trace. Objek SensitiveParameterValue merangkum nilai parameter aktual — jika Anda membutuhkannya karena alasan apa pun.

Fungsi mysqli_execute_query baru dan Metode mysqli::execute_query

Pernahkah Anda menggunakan fungsi mysqli_query() dengan menghindari nilai pengguna yang berbahaya hanya untuk menjalankan kueri MySQLi berparameter?

PHP 8.2 membuat menjalankan kueri MySQLi berparameter lebih mudah dengan fungsi mysqli_execute_query($sql, $params) baru dan metode mysqli::execute_query .

Pada dasarnya, fungsi baru ini adalah kombinasi dari mysqli_prepare() , mysqli_execute() , dan mysqli_stmt_get_result() . Dengan itu, kueri MySQLi akan disiapkan, diikat (jika Anda melewati parameter apa pun), dan dieksekusi di dalam fungsi itu sendiri. Jika kueri berhasil dijalankan, itu akan mengembalikan objek mysqli_result . Jika tidak berhasil, itu akan mengembalikan false .

Proposal RFC memberikan contoh sederhana namun kuat:

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

Ambil Properti enum dalam ekspresi const

RFC ini mengusulkan untuk mengizinkan operator ->/?-> untuk mengambil properti enum dalam ekspresi const .

Alasan utama untuk fitur baru ini adalah Anda tidak dapat menggunakan objek enum di beberapa tempat, seperti kunci array. Dalam kasus seperti itu, Anda harus mengulangi nilai enum hanya untuk menggunakannya.

Mengizinkan pengambilan properti enum di tempat-tempat di mana objek enum tidak diizinkan dapat menyederhanakan prosedur ini.

Ini berarti kode berikut sekarang valid:

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

Dan untuk amannya, RFC ini juga menyertakan dukungan untuk operator nullsafe ?-> .

Izinkan Konstanta dalam Sifat

PHP menyertakan cara untuk menggunakan kembali kode yang disebut Traits. Mereka bagus untuk penggunaan kembali kode di seluruh kelas.

Saat ini, Traits hanya mengizinkan untuk mendefinisikan metode dan properti, tetapi tidak untuk konstanta. Itu berarti Anda tidak dapat mendefinisikan invarian yang diharapkan oleh suatu Sifat di dalam Sifat itu sendiri. Untuk mengatasi batasan ini, Anda perlu mendefinisikan konstanta di kelas penyusunnya atau antarmuka yang diimplementasikan oleh kelas penyusunnya.

RFC ini mengusulkan untuk memungkinkan mendefinisikan konstanta dalam Sifat. Konstanta ini dapat didefinisikan seperti Anda mendefinisikan konstanta kelas. Contoh ini diambil langsung dari RFC membersihkan udara di sekitar penggunaannya:

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

Konstanta sifat juga digabungkan ke dalam definisi kelas penyusun, sama seperti definisi properti dan metode sifat. Mereka juga memiliki batasan yang sama dengan sifat Sifat. Seperti disebutkan dalam RFC, proposal ini — meskipun awal yang baik — membutuhkan pekerjaan lebih lanjut untuk menyempurnakan fitur tersebut.

Penghentian di PHP 8.2

Kita sekarang dapat bergerak untuk menjelajahi semua penghentian di PHP 8.2. Daftar ini tidak sebesar fitur barunya:

Menghentikan Properti Dinamis (dan Atribut #[AllowDynamicProperties] )

Hingga PHP 8.1, Anda dapat secara dinamis mengatur dan mengambil properti kelas yang tidak dideklarasikan di PHP. Sebagai contoh:

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

Di sini, kelas Post tidak mendeklarasikan properti name . Tetapi karena PHP mengizinkan properti dinamis, Anda dapat mengaturnya di luar deklarasi kelas. Itulah keuntungan terbesarnya — dan mungkin, satu-satunya —.

Properti dinamis memungkinkan bug dan perilaku tak terduga muncul dalam kode Anda. Misalnya, jika Anda membuat kesalahan saat mendeklarasikan properti kelas di luar kelas, Anda akan mudah kehilangan jejaknya — terutama saat men-debug kesalahan apa pun di dalam kelas itu.

Mulai dari PHP 8.2 dan seterusnya, properti dinamis tidak digunakan lagi. Menyetel nilai ke properti kelas yang tidak dideklarasikan akan mengeluarkan pemberitahuan penghentian saat pertama kali properti disetel.

 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;

Namun, mulai dari PHP 9.0 dan seterusnya, pengaturan yang sama akan menimbulkan kesalahan ErrorException .

Jika kode Anda penuh dengan properti dinamis — dan ada banyak kode PHP — dan jika Anda ingin menghentikan pemberitahuan penghentian ini setelah memutakhirkan ke PHP 8.2, Anda dapat menggunakan atribut #[AllowDynamicProperties] baru PHP 8.2 untuk mengizinkan dinamis properti di kelas.

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

Sesuai RFC, kelas yang ditandai sebagai #[AllowDynamicProperties] , serta kelas turunannya, dapat terus menggunakan properti dinamis tanpa penghentian atau penghapusan.

Anda juga harus mencatat bahwa, dalam PHP 8.2, satu-satunya kelas paket yang ditandai sebagai #[AllowDynamicProperties] adalah stdClass . Selain itu, setiap properti yang diakses melalui __get() atau __set() metode ajaib PHP tidak dianggap sebagai properti dinamis, sehingga tidak akan memberikan pemberitahuan penghentian.

Menghentikan Callable yang Didukung Sebagian

Perubahan PHP 8.2 lainnya, meskipun dengan dampak yang lebih dapat diabaikan, adalah menghentikan penggunaan callable yang didukung sebagian.

Callable ini disebut didukung sebagian karena Anda tidak dapat berinteraksi dengan mereka secara langsung melalui $callable() . Anda hanya dapat mengaksesnya dengan fungsi call_user_func($callable) . Daftar callables tersebut tidak panjang:

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

Dari PHP 8.2 dan seterusnya, setiap upaya untuk memanggil callable semacam itu — seperti melalui fungsi call_user_func() atau array_map() — akan mengeluarkan peringatan penghentian.

RFC asli memberikan alasan kuat di balik penghentian ini:

Terlepas dari dua kasus terakhir, semua callable ini bergantung pada konteks. Metode yang dirujuk oleh "self::method" bergantung pada kelas mana panggilan atau pemeriksaan panggilan dilakukan. Dalam praktiknya, ini biasanya juga berlaku untuk dua kasus terakhir, ketika digunakan dalam bentuk [new Foo, "parent::method"] .

Mengurangi ketergantungan konteks dari callable adalah tujuan sekunder dari RFC ini. Setelah RFC ini, satu-satunya ketergantungan lingkup yang masih tersisa adalah visibilitas metode: "Foo::bar" mungkin terlihat di satu lingkup, tetapi tidak di lingkup lain. Jika callable dibatasi pada metode publik di masa mendatang (sementara metode privat harus menggunakan callable kelas satu atau Closure::fromCallable() untuk dibuat tidak bergantung pada cakupan), maka tipe yang dapat dipanggil akan menjadi terdefinisi dengan baik dan dapat digunakan sebagai tipe properti. Namun, perubahan penanganan visibilitas tidak diusulkan sebagai bagian dari RFC ini .

Sesuai dengan RFC asli, fungsi is_callable() dan tipe callable akan terus menerima callable ini sebagai pengecualian. Tetapi hanya sampai dukungan untuk mereka dihapus seluruhnya dari PHP 9.0 dan seterusnya.

Untuk menghindari kebingungan, cakupan pemberitahuan penghentian ini diperluas dengan RFC baru — sekarang mencakup pengecualian ini.

Ada baiknya melihat PHP bergerak ke arah memiliki tipe callable yang terdefinisi dengan baik.

#utf8_encode() dan utf8_decode()

Fungsi bawaan PHP utf8_encode() dan utf8_decode() mengonversi string yang dikodekan dalam ISO-8859-1 (“Latin 1”) ke dan dari UTF-8.

Namun, nama mereka menyarankan penggunaan yang lebih umum daripada yang diizinkan oleh implementasinya. Pengkodean "Latin 1" biasanya dikacaukan dengan pengkodean lain seperti "Windows Code Page 1252."

Selanjutnya, Anda biasanya akan melihat Mojibake ketika fungsi-fungsi ini tidak dapat mengonversi string apa pun dengan benar. Kurangnya pesan kesalahan juga berarti sulit untuk menemukannya, terutama di dalam lautan teks yang dapat dibaca.

PHP 8.2 tidak lagi menggunakan #utf8_encode() dan utf8_decode() . Jika Anda memanggilnya, Anda akan melihat pemberitahuan penghentian ini:

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

RFC menyarankan untuk menggunakan ekstensi yang didukung PHP seperti mbstring , iconv , dan intl sebagai gantinya.

Menghentikan Interpolasi String ${}

PHP memungkinkan penyematan variabel dalam string dengan tanda kutip ganda ( " ) dan heredoc ( <<< ) dalam beberapa cara:

1. Memasukkan variabel secara langsung — “$foo”
2. Dengan kurung kurawal di luar variabel — “{$foo}”
3. Dengan kurung kurawal setelah tanda dolar — “${foo}”
4. Variabel variabel — “${expr}” — setara dengan menggunakan (string) ${expr}

Dua cara pertama memiliki pro dan kontra, sedangkan dua yang terakhir memiliki sintaks yang kompleks dan saling bertentangan. PHP 8.2 tidak menggunakan dua cara terakhir untuk interpolasi string.

Anda harus menghindari interpolasi string dengan cara ini ke depan:

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

Dimulai dengan PHP 9.0, penghentian ini akan ditingkatkan untuk memunculkan kesalahan pengecualian.

Menghentikan Fungsi mbstring untuk Entitas Base64/QPrint/Uuencode/HTML

Fungsi mbstring (string multi-byte) PHP membantu kami bekerja dengan Unicode, entitas HTML, dan pengkodean teks warisan lainnya.

Namun, Base64, Uuencode, dan QPrint bukan penyandian teks dan masih merupakan bagian dari fungsi ini — terutama karena alasan warisan. PHP juga menyertakan implementasi terpisah dari pengkodean ini.

Untuk entitas HTML, PHP memiliki fungsi bawaan — htmlspecialchars() dan htmlentities() — untuk menanganinya dengan lebih baik. Misalnya, tidak seperti mbstring, fungsi ini juga akan mengonversi < . > , dan & karakter ke entitas HTML.

Selain itu, PHP selalu meningkatkan fungsi bawaannya — sama seperti PHP 8.1 dengan fungsi encoding dan decoding HTML.

Jadi, dengan mengingat semua itu, PHP 8.2 tidak lagi menggunakan mbstring untuk penyandian ini (labelnya tidak peka huruf besar-kecil):

• BASE64
• KODE UUEN
• HTML-ENTITAS
• html (alias HTML-ENTITIES)
• Dikutip-Dapat Dicetak
• qprint (alias Quoted-Printable)

Dari PHP 8.2 dan seterusnya, menggunakan mbstring untuk menyandikan/mendekodekan salah satu hal di atas akan mengeluarkan pemberitahuan penghentian. PHP 9.0 akan menghapus dukungan mbstring untuk penyandian ini sama sekali.

Perubahan Kecil Lainnya di PHP 8.2

Terakhir, kita dapat mendiskusikan perubahan kecil PHP 8.2, termasuk fitur dan fungsionalitas yang dihapus.

Hapus Dukungan untuk libmysql dari mysqli

Sampai sekarang, PHP memungkinkan driver mysqli dan PDO_mysql untuk membangun perpustakaan mysqlnd dan libmysql . Namun, driver default dan yang direkomendasikan sejak PHP 5.4 adalah mysqlnd .

Kedua driver ini memiliki banyak kelebihan dan kekurangan. Namun, menghapus dukungan untuk salah satunya — idealnya, menghapus libmysql karena bukan default — akan menyederhanakan pengujian kode dan unit PHP.

Untuk membuat argumen untuk mendukung ini, RFC mencantumkan banyak keuntungan dari mysqlnd :

• Ini dibundel dengan PHP
• Ini menggunakan manajemen memori PHP untuk memantau penggunaan memori dan
  meningkatkan kinerja
• Menyediakan fungsi kualitas hidup (misalnya get_result() )
• Mengembalikan nilai numerik menggunakan tipe asli PHP
• Fungsinya tidak bergantung pada perpustakaan eksternal
• Fungsionalitas plugin opsional
• Mendukung kueri asinkron

RFC juga mencantumkan beberapa keunggulan libmysql , termasuk:

• Koneksi ulang otomatis dimungkinkan ( mysqlnd tidak mendukung fungsi ini dengan sengaja karena dapat dengan mudah dieksploitasi)
• Mode otentikasi LDAP dan SASL ( mysqlnd mungkin akan segera menambahkan fitur ini juga)

Selain itu, RFC mencantumkan banyak kelemahan libmysql — ketidakcocokan dengan model memori PHP, banyak tes yang gagal, kebocoran memori, fungsionalitas yang berbeda antar versi, dll.

Dengan mengingat semua ini, PHP 8.2 menghapus dukungan untuk membangun mysqli terhadap libmysql .

Jika Anda ingin menambahkan fungsionalitas apa pun yang hanya tersedia dengan libmysql , Anda harus menambahkannya secara eksplisit ke mysqlnd sebagai permintaan fitur. Selain itu, Anda tidak dapat menambahkan koneksi ulang otomatis.

Konversi Kasus Lokal-Independen

Sebelum PHP 8.0, lokal PHP diwarisi dari lingkungan sistem. Tetapi ini dapat menyebabkan masalah dalam beberapa kasus tepi.

Menyetel bahasa Anda saat menginstal Linux akan mengatur bahasa antarmuka pengguna yang sesuai untuk perintah bawaannya. Namun, ini juga secara tidak terduga mengubah cara kerja fungsionalitas penanganan string pustaka C.

Misalnya, jika Anda memilih bahasa "Turki" atau "Kazakh" saat menginstal Linux, Anda akan menemukan bahwa memanggil toupper('i') untuk mendapatkan padanan huruf besar akan mendapatkan huruf kapital bertitik I (U+0130, I ).

PHP 8.0 menghentikan anomali ini dengan menyetel lokal default ke “C”, kecuali jika pengguna secara eksplisit mengubahnya melalui setlocale() .

PHP 8.2 melangkah lebih jauh dengan menghapus sensitivitas lokal dari konversi huruf besar-kecil. RFC ini terutama mengubah strtolower() , strtoupper() , dan fungsi terkait. Baca RFC untuk daftar semua fungsi yang terpengaruh.

Sebagai alternatif, jika Anda ingin menggunakan konversi kasus yang dilokalkan, Anda dapat menggunakan mb_strtolower() .

Peningkatan Ekstensi Acak

PHP berencana untuk merombak fungsionalitas acaknya.

Sampai sekarang, fungsionalitas acak PHP sangat bergantung pada status Mersenne Twister. Namun, status ini secara implisit disimpan di area global PHP — tidak mungkin pengguna dapat mengaksesnya. Menambahkan fungsi pengacakan antara tahap penyemaian awal dan penggunaan yang dimaksudkan akan merusak kode.

Mempertahankan kode tersebut bisa menjadi lebih rumit ketika kode Anda menggunakan paket eksternal.

Dengan demikian, fungsi acak PHP saat ini tidak dapat mereproduksi nilai acak secara konsisten. Ia bahkan gagal dalam uji statistik empiris dari generator bilangan acak yang seragam, seperti Crush dan BigCrush TestU01. Keterbatasan 32-bit Mersenne Twister semakin memperburuk itu.

Jadi, menggunakan fungsi bawaan PHP — shuffle() , str_shuffle() , array_rand() — tidak disarankan jika Anda memerlukan nomor acak yang aman secara kriptografis. Dalam kasus seperti itu, Anda harus mengimplementasikan fungsi baru menggunakan random_int() atau fungsi serupa.

Namun, beberapa masalah dengan RFC ini muncul setelah pemungutan suara dimulai. Kemunduran ini memaksa tim PHP untuk mencatat semua masalah dalam RFC terpisah, dengan opsi pemungutan suara dibuat untuk setiap masalah. Mereka akan memutuskan untuk bergerak lebih jauh hanya setelah mencapai konsensus.

RFC tambahan di PHP 8.2

PHP 8.2 juga mencakup banyak fungsi baru dan perubahan kecil. Kami akan menyebutkannya di bawah dengan tautan ke sumber daya tambahan:

1. Fungsi curl_upkeep baru: PHP 8.2 menambahkan fungsi baru ini ke ekstensi Curl-nya. Ini memanggil fungsi curl_easy_upkeep() di libcurl, pustaka C dasar yang digunakan ekstensi PHP Curl.
2. Fungsi ini_parse_quantity baru: Arahan PHP INI menerima ukuran data dengan sufiks pengganda. Misalnya, Anda dapat menulis 25 Megabyte sebagai 25M , atau 42 Gigabyte hanya sebagai 42G . Sufiks ini umum di file PHP INI tetapi tidak umum di tempat lain. Fungsi baru ini mem-parsing nilai PHP INI dan mengembalikan ukuran datanya dalam byte.
3. Fungsi memory_reset_peak_usage baru: Fungsi ini mengatur ulang penggunaan memori puncak yang dikembalikan oleh fungsi memory_get_peak_usage . Ini bisa berguna saat Anda menjalankan tindakan yang sama beberapa kali dan ingin merekam penggunaan memori puncak setiap proses.
4. Dukungan untuk pengubah no-capture ( /n ) di fungsi preg_* : Dalam regex, metakarakter () menunjukkan grup penangkap. Itu berarti semua kecocokan untuk ekspresi di dalam kurung dikembalikan. PHP 8.2 menambahkan pengubah no-capture ( /n ) untuk menghentikan perilaku ini.
5. Jadikan keluarga iterator_*() menerima semua iterables: Sampai sekarang, keluarga iterator_*() PHP hanya menerima \Traversables (yaitu tidak ada array biasa yang diizinkan). Ini tidak perlu membatasi, dan RFC ini memperbaikinya.

Ringkasan

PHP 8.2 dibangun di atas perbaikan besar-besaran di PHP 8.0 dan PHP 8.1, yang bukan hal mudah. Kami pikir fitur PHP 8.2 yang paling menarik adalah tipe mandiri baru, properti hanya baca, dan banyak peningkatan kinerja.

Kami tidak sabar untuk melakukan benchmark PHP 8.2 dengan berbagai framework PHP dan CMS.

Pastikan untuk menandai posting blog ini untuk referensi Anda di masa mendatang.

Fitur PHP 8.2 mana yang menjadi favorit Anda? Penghinaan mana yang paling tidak Anda sukai? Silakan bagikan pemikiran Anda dengan komunitas kami di komentar!