Co nowego w PHP 8.2 — nowe funkcje, wycofania, zmiany i nie tylko

PHP 8.2 opiera się na odnowionej bazie przedstawionej przez PHP 8.0 i PHP 8.1. Jego premiera planowana jest na 24 listopada 2022 r.

W tym artykule szczegółowo omówimy nowości w PHP 8.2 — od nowych funkcji i ulepszeń po wycofania i drobne zmiany, omówimy je wszystkie.

Ponieważ PHP 8.2 zamroziło się 19 lipca 2022 r., nie można spodziewać się żadnych znaczących dodatków do tej listy.

Podekscytowany? Dokąd.

Zaczynajmy!

Nowe funkcje i ulepszenia w PHP 8.2

Zacznijmy od zbadania wszystkich najnowszych funkcji PHP 8.2. To dość obszerna lista:

Nowe klasy readonly

PHP 8.1 wprowadziło funkcję tylko do readonly dla właściwości klas. Teraz PHP 8.2 dodaje obsługę deklarowania całej klasy jako readonly .

Jeśli zadeklarujesz klasę jako readonly , wszystkie jej właściwości automatycznie odziedziczą funkcję readonly . W związku z tym deklarowanie klasy tylko do readonly jest tym samym, co deklarowanie każdej właściwości klasy jako tylko do readonly .

Na przykład w PHP 8.1 musiałeś napisać ten żmudny kod, aby zadeklarować wszystkie właściwości klasy jako tylko do readonly :

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

Wyobraź sobie to samo z wieloma innymi właściwościami. Teraz, w PHP 8.2, możesz po prostu napisać to:

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

Możesz również zadeklarować klasy abstrakcyjne lub końcowe jako tylko do readonly . Tutaj kolejność słów kluczowych nie ma znaczenia.

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

Możesz również zadeklarować klasę tylko do readonly bez właściwości. Skutecznie zapobiega to właściwościom dynamicznym, jednocześnie umożliwiając klasom podrzędnym jawne deklarowanie ich właściwości tylko do readonly .

Następnie klasy tylko do readonly mogą zawierać tylko właściwości wpisane — ta sama reguła dotyczy deklarowania poszczególnych właściwości tylko do odczytu .

Możesz użyć właściwości typu mixed , jeśli nie możesz zadeklarować właściwości ściśle określonej.

Próba zadeklarowania klasy tylko do readonly bez właściwości typu spowoduje błąd krytyczny:

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

Co więcej, nie możesz deklarować tylko do readonly dla niektórych funkcji PHP:

• Wyliczenia (ponieważ nie mogą zawierać żadnej właściwości)
• Cechy
• Interfejsy

Próba zadeklarowania dowolnej z tych funkcji jako tylko do readonly spowoduje błąd analizy.

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

Podobnie jak w przypadku wszystkich słów kluczowych PHP, słowo kluczowe readonly nie uwzględnia wielkości liter.

PHP 8.2 również deprecjonuje właściwości dynamiczne (więcej o tym później). Nie można jednak uniemożliwić dodawania właściwości dynamicznych do klasy. Jednak zrobienie tego dla klasy tylko do readonly spowoduje tylko błąd krytyczny.

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

Zezwalaj na true , false i null jako samodzielne typy

PHP zawiera już typy skalarne, takie jak int , string i bool . Zostało to rozszerzone w PHP 8.0 z dodaniem typów unii, pozwalających wartościom być różnych typów. Ten sam dokument RFC zezwalał również na używanie wartości false i null jako części typu unii — nie były one jednak dozwolone jako typy samodzielne.

Jeśli próbowałeś zadeklarować false , null lub jako typy autonomiczne — bez ich przynależności do typu union — skutkowało to błędem krytycznym.

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

Aby uniknąć tego scenariusza, PHP 8.2 dodaje obsługę używania false i null jako samodzielnych typów. Dzięki temu dodatkowi system typów PHP jest bardziej wyrazisty i kompletny. Teraz możesz precyzyjnie zadeklarować typy zwracane, parametry i właściwości.

Ponadto PHP nadal nie zawiera typu true , który wydaje się być naturalnym odpowiednikiem typu false . PHP 8.2 naprawia to i dodaje również wsparcie dla true typu. Nie pozwala na przymus, dokładnie tak, jak zachowuje się false typ.

Zarówno typy true jak i false są zasadniczo typem unii typu bool PHP. Aby uniknąć nadmiarowości, nie można zadeklarować tych trzech typów razem w typie unii. Spowoduje to błąd krytyczny w czasie kompilacji.

Rozłączne typy postaci normalnej (DNF)

Disjunctive Normal Form (DNF) to ustandaryzowany sposób organizowania wyrażeń logicznych. Składa się z alternatywy spójników — w kategoriach logicznych jest to OR z AND .

Zastosowanie DNF do deklaracji typu pozwala na standardowy sposób pisania połączonych typów Union i Intersection, które może obsłużyć parser. Nowa funkcja typów DNF w PHP 8.2 jest prosta, ale potężna, jeśli jest używana prawidłowo.

RFC podaje następujący przykład. Zakłada, że ​​istnieją już następujące definicje interfejsów i klas:

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

W przypadku typów DNF można wykonywać deklaracje typów dla właściwości, parametrów i wartości zwracanych, takich jak:

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

W niektórych przypadkach właściwości mogą nie mieć formy DNF. Zadeklarowanie ich jako takich spowoduje błąd analizy. Ale zawsze możesz je przepisać jako:

 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

Należy pamiętać, że każdy segment typu DNF musi być unikalny. Na przykład deklaracja (A&B)|(B&A) jest nieprawidłowa, ponieważ dwa segmenty OR ed są logicznie takie same.

Dodając do tego, segmenty, które są ścisłymi podzbiorami drugiego segmentu, również nie są dozwolone. Dzieje się tak, ponieważ nadzbiór będzie już zawierał wszystkie wystąpienia podzbioru, co sprawia, że ​​korzystanie z DNF jest zbędne.

Usuń wrażliwe parametry w śladach wstecznych

Jak prawie każdy język programowania, PHP umożliwia śledzenie stosu wywołań w dowolnym momencie wykonywania kodu. Śledzenie stosu ułatwia debugowanie kodu w celu naprawienia błędów i wąskich gardeł wydajności. Stanowi podstawę narzędzi takich jak Kinsta APM, nasze niestandardowe narzędzie do monitorowania wydajności dla witryn WordPress.

Wykonywanie śledzenia stosu nie zatrzymuje wykonywania programu. Zazwyczaj większość śladów stosu działa w tle i jest rejestrowana po cichu — w razie potrzeby do późniejszej kontroli.

Jednak niektóre z tych szczegółowych śladów stosu PHP mogą być wadą, jeśli udostępniasz je usługom innych firm — zwykle do analizy dziennika błędów, śledzenia błędów itp. Te ślady stosu mogą zawierać poufne informacje takie jak nazwy użytkowników, hasła i zmienne środowiskowe .

Ta propozycja RFC podaje jeden taki przykład:

Jednym z powszechnych „przestępców” jest PDO, które przyjmuje hasło bazy danych jako parametr konstruktora i natychmiast próbuje połączyć się z bazą danych w konstruktorze, zamiast mieć czysty konstruktor i oddzielną metodę ->connect() . Tak więc, gdy połączenie z bazą danych nie powiedzie się, ślad stosu będzie zawierał hasło do bazy danych:

 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 pozwala na oznaczenie tak wrażliwych parametrów nowym atrybutem \SensitiveParameter . Żaden parametr oznaczony jako wrażliwy nie zostanie wymieniony w Twoich śladach wstecznych. W ten sposób możesz udostępniać je bez obaw jakimkolwiek usługom stron trzecich.

Oto prosty przykład z jednym wrażliwym parametrem:

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

Podczas generowania śladu wstecznego każdy parametr z atrybutem \SensitiveParameter zostanie zastąpiony obiektem \SensitiveParameterValue , a jego wartość rzeczywista nigdy nie będzie przechowywana w śladzie. Obiekt SensitiveParameterValue hermetyzuje rzeczywistą wartość parametru — jeśli jest ona potrzebna z jakiegokolwiek powodu.

Nowa funkcja mysqli_execute_query i metoda mysqli::execute_query

Czy kiedykolwiek używałeś funkcji mysqli_query() z niebezpiecznie wymykającymi się wartościami użytkownika tylko po to, aby uruchomić sparametryzowane zapytanie MySQLi?

PHP 8.2 ułatwia uruchamianie sparametryzowanych zapytań MySQLi dzięki nowej mysqli_execute_query($sql, $params) i metodzie mysqli::execute_query .

Zasadniczo ta nowa funkcja jest kombinacją funkcji mysqli_prepare() , mysqli_execute() i mysqli_stmt_get_result() . Dzięki niemu zapytanie MySQLi zostanie przygotowane, powiązane (jeśli podasz jakieś parametry) i wykonane w samej funkcji. Jeśli zapytanie zostanie wykonane pomyślnie, zwróci obiekt mysqli_result . Jeśli się nie powiedzie, zwróci false .

Propozycja RFC daje prosty, ale mocny przykład:

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

Pobierz właściwości enum w wyrażeniach const

Ten dokument RFC proponuje umożliwienie operatorowi ->/?-> pobierania właściwości enum w wyrażeniach const .

Głównym powodem tej nowej funkcji jest to, że w niektórych miejscach nie można używać obiektów enum , takich jak klucze tablicowe. W takim przypadku będziesz musiał powtórzyć wartość przypadku enum , aby go użyć.

Zezwolenie na pobieranie właściwości enum w miejscach, w których obiekty enum nie są dozwolone, może uprościć tę procedurę.

Oznacza to, że następujący kod jest teraz ważny:

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

Aby być bezpiecznym, ten dokument RFC zawiera również obsługę operatora nullsafe ?-> .

Zezwalaj na stałe w cechach

PHP zawiera sposób na ponowne wykorzystanie kodu o nazwie Cechy. Świetnie nadają się do ponownego wykorzystania kodu w różnych klasach.

Obecnie cechy pozwalają jedynie na definiowanie metod i właściwości, ale nie stałych. Oznacza to, że nie możesz zdefiniować niezmienników oczekiwanych przez cechę w samej cesze. Aby obejść to ograniczenie, musisz zdefiniować stałe w jego klasie tworzącej lub interfejsie zaimplementowanym przez jego klasę tworzącą.

Ten dokument RFC proponuje umożliwienie definiowania stałych w cechach. Te stałe można zdefiniować tak, jak definiuje się stałe klas. Ten przykład zaczerpnięty prosto z RFC oczyszcza powietrze wokół jego użycia:

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

Stałe cech są również scalane z definicją klasy tworzącej, tak samo jak definicje właściwości i metod cech. Mają też podobne ograniczenia jak właściwości Cech. Jak zauważono w RFC, ta propozycja — choć dobry początek — wymaga dalszych prac, aby dopracować tę funkcję.

Deprecjacje w PHP 8.2

Możemy teraz przejść do zbadania wszystkich przestarzałych wersji PHP 8.2. Ta lista nie jest tak duża, jak jej nowe funkcje:

Wycofaj właściwości dynamiczne (i nowy #[AllowDynamicProperties] )

Aż do PHP 8.1 można było dynamicznie ustawiać i pobierać niezadeklarowane właściwości klas w PHP. Na przykład:

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

Tutaj klasa Post nie deklaruje właściwości name . Ale ponieważ PHP dopuszcza właściwości dynamiczne, możesz ustawić je poza deklaracją klasy. To jego największa — i prawdopodobnie jedyna — zaleta.

Właściwości dynamiczne pozwalają na pojawienie się w kodzie nieoczekiwanych błędów i zachowań. Na przykład, jeśli popełnisz jakiś błąd podczas deklarowania właściwości klasy poza klasą, łatwo zgubić to — zwłaszcza podczas debugowania jakichkolwiek błędów w tej klasie.

Od PHP 8.2 wzwyż właściwości dynamiczne są przestarzałe. Ustawienie wartości na niezadeklarowaną właściwość klasy spowoduje wyemitowanie powiadomienia o wycofaniu przy pierwszym ustawieniu właściwości.

 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;

Jednak od PHP 9.0 ustawienie tego samego spowoduje wygenerowanie błędu ErrorException .

Jeśli Twój kod jest pełen właściwości dynamicznych — a jest dużo kodu PHP — i jeśli chcesz zatrzymać te powiadomienia o wycofaniu po aktualizacji do PHP 8.2, możesz użyć nowego atrybutu #[AllowDynamicProperties] PHP 8.2, aby umożliwić dynamiczne właściwości na klasach.

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

Zgodnie z dokumentem RFC klasy oznaczone jako #[AllowDynamicProperties] , a także ich klasy podrzędne, mogą nadal korzystać z właściwości dynamicznych bez wycofywania lub usuwania.

Należy również zauważyć, że w PHP 8.2 jedyną spakowaną klasą oznaczoną jako #[AllowDynamicProperties] jest stdClass . Co więcej, wszelkie właściwości dostępne za pomocą magicznych metod PHP __get() lub __set() nie są uważane za właściwości dynamiczne, więc nie spowodują powiadomienia o wycofaniu.

Wycofaj się z częściowo obsługiwanych połączeń telefonicznych

Kolejną zmianą w PHP 8.2, aczkolwiek o mniejszym wpływie, jest wycofanie częściowo obsługiwanych funkcji callable.

Te wywołania są określane jako częściowo obsługiwane, ponieważ nie można z nimi komunikować się bezpośrednio przez $callable() . Możesz się do nich dostać tylko za pomocą call_user_func($callable) . Lista takich callables nie jest długa:

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

Począwszy od PHP 8.2, wszelkie próby wywołania takich wywołań — na przykład przez funkcje call_user_func() lub array_map() — spowodują wyświetlenie ostrzeżenia o wycofaniu.

Pierwotny dokument RFC podaje solidne uzasadnienie tego wycofania:

Oprócz dwóch ostatnich przypadków, wszystkie te wywoływalne są zależne od kontekstu. Metoda, do której odnosi się "self::method" , zależy od klasy, z której wykonywane jest wywołanie lub sprawdzanie możliwości wywołania. W praktyce zwykle odnosi się to również do dwóch ostatnich przypadków, gdy jest używane w postaci [new Foo, "parent::method"] .

Redukcja zależności od kontekstu wywołań jest drugorzędnym celem tego dokumentu RFC. Po tym dokumencie RFC jedyną pozostałą zależnością zakresu jest widoczność metody: "Foo::bar" może być widoczny w jednym zakresie, ale nie w innym. Jeśli callables miałyby być w przyszłości ograniczone do metod publicznych (podczas gdy metody prywatne musiałyby używać funkcji callable pierwszej klasy lub Closure::fromCallable() , aby były niezależne od zakresu), wtedy typ callable stałby się dobrze zdefiniowany i mógłby być używany jako typ właściwości. Jednak zmiany w obsłudze widoczności nie są proponowane jako część tego RFC .

Zgodnie z oryginalnym RFC funkcja is_callable() i typ callable będą nadal akceptować te wywoływalne jako wyjątki. Ale tylko do czasu, gdy ich obsługa zostanie całkowicie usunięta od PHP 9.0.

Aby uniknąć nieporozumień, ten zakres powiadomienia o wycofaniu został rozszerzony o nowy dokument RFC — zawiera teraz te wyjątki.

Dobrze jest widzieć, jak PHP zmierza w kierunku posiadania dobrze zdefiniowanego typu callable .

#utf8_encode() i utf8_decode()

Wbudowane funkcje utf8_encode() i utf8_decode() konwertują ciągi zakodowane w ISO-8859-1 („Latin 1”) do i z UTF-8.

Jednak ich nazwy sugerują bardziej ogólne zastosowanie niż pozwala na to ich implementacja. Kodowanie "Latin 1" jest często mylone z innymi kodowaniami, takimi jak "Strona kodowa systemu Windows 1252".

Co więcej, zwykle zobaczysz Mojibake, gdy te funkcje nie mogą poprawnie przekonwertować żadnego ciągu. Brak komunikatów o błędach oznacza również, że trudno je zauważyć, zwłaszcza w morzu czytelnego tekstu.

PHP 8.2 deprecjonuje obie #utf8_encode() i utf8_decode() . Jeśli je wywołasz, zobaczysz te powiadomienia o wycofaniu:

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

RFC sugeruje użycie rozszerzeń obsługiwanych przez PHP, takich jak mbstring , iconv i intl .

Wycofaj interpolację ciągów ${}

PHP umożliwia osadzanie zmiennych w łańcuchach z podwójnymi cudzysłowami ( " ) i heredoc ( <<< ) na kilka sposobów:

1. Bezpośrednie osadzanie zmiennych — “$foo”
2. Z nawiasami klamrowymi poza zmienną — “{$foo}”
3. Z nawiasami klamrowymi po znaku dolara — “${foo}”
4. Zmienne zmienne — “${expr}” — równoważne użyciu (string) ${expr}

Pierwsze dwa sposoby mają swoje zalety i wady, podczas gdy dwa ostatnie mają złożoną i sprzeczną składnię. PHP 8.2 deprecjonuje dwa ostatnie sposoby interpolacji łańcuchów.

Powinieneś unikać interpolowania ciągów w ten sposób w przód:

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

Począwszy od PHP 9.0, te deprecjacje zostaną zaktualizowane, aby zgłosić błąd wyjątku.

Przestarzałe funkcje mbstring dla jednostek Base64/QPrint/Uuencode/HTML

Funkcje PHP mbstring (ciągi wielobajtowe) pomagają nam pracować z Unicode, encjami HTML i innymi starszymi kodowaniami tekstu.

Jednak Base64, Uuencode i QPrint nie są kodowaniami tekstu i nadal są częścią tych funkcji — głównie ze względu na starsze przyczyny. PHP zawiera również oddzielne implementacje tych kodowań.

Jeśli chodzi o encje HTML, PHP ma wbudowane funkcje — htmlspecialchars() i htmlentities() — aby lepiej sobie z nimi radzić. Na przykład, w przeciwieństwie do mbstring, te funkcje również przekonwertują < . > i & znaków do encji HTML.

Co więcej, PHP zawsze ulepsza swoje wbudowane funkcje — podobnie jak PHP 8.1 z funkcjami kodowania i dekodowania HTML.

Mając to wszystko na uwadze, PHP 8.2 wycofuje użycie mbstring dla tych kodowań (etykiety nie uwzględniają wielkości liter):

• PODSTAWA64
• KOD UUEN
• ELEMENTY HTML
• html (alias encji HTML)
• Cytowane-do druku
• qprint (alias Cytowany-Do druku)

Od PHP 8.2 wzwyż, użycie mbstring do kodowania/dekodowania któregokolwiek z powyższych spowoduje wyświetlenie komunikatu o wycofaniu. PHP 9.0 całkowicie usunie obsługę mbstring dla tych kodowań.

Inne drobne zmiany w PHP 8.2

Na koniec możemy omówić drobne zmiany w PHP 8.2, w tym usunięte funkcje i funkcjonalności.

Usuń obsługę libmysql z mysqli

Obecnie PHP pozwala zarówno sterownikom mysqli , jak i PDO_mysql budować z bibliotekami mysqlnd i libmysql . Jednak domyślnym i zalecanym sterownikiem od PHP 5.4 jest mysqlnd .

Oba te sterowniki mają wiele zalet i wad. Jednak usunięcie wsparcia dla jednego z nich — najlepiej usunięcie libmysql , ponieważ nie jest to ustawienie domyślne — uprości kod PHP i testy jednostkowe.

Aby uzasadnić tę przysługę, RFC wymienia wiele zalet mysqlnd :

• Jest w pakiecie z PHP
• Wykorzystuje zarządzanie pamięcią PHP do monitorowania wykorzystania pamięci i
  ulepszyć wydajność
• Zapewnia funkcje jakości życia (np get_result() )
• Zwraca wartości liczbowe przy użyciu natywnych typów PHP
• Jego funkcjonalność nie zależy od zewnętrznej biblioteki
• Opcjonalna funkcjonalność wtyczki
• Obsługuje zapytania asynchroniczne

RFC wymienia również niektóre zalety libmysql , w tym:

• Możliwe jest automatyczne ponowne łączenie ( mysqlnd nie obsługuje celowo tej funkcjonalności, ponieważ można ją łatwo wykorzystać)
• Tryby uwierzytelniania LDAP i SASL ( mysqlnd może wkrótce dodać tę funkcję)

Ponadto RFC wymienia wiele wad libmysql — niezgodność z modelem pamięci PHP, wiele nieudanych testów, wycieki pamięci, różne funkcjonalności między wersjami itp.

Mając to wszystko na uwadze, PHP 8.2 usunęło wsparcie dla budowania mysqli przeciwko libmysql .

Jeśli chcesz dodać jakąkolwiek funkcjonalność, która jest dostępna tylko w libmysql , musisz dodać ją jawnie do mysqlnd jako żądanie funkcji. Ponadto nie można dodać automatycznego ponownego łączenia.

Niezależna od lokalizacji konwersja wielkości liter

Przed PHP 8.0 ustawienia regionalne PHP były dziedziczone ze środowiska systemowego. Ale może to spowodować problem w niektórych skrajnych przypadkach.

Ustawienie języka podczas instalacji Linuksa ustawi odpowiedni język interfejsu użytkownika dla jego wbudowanych poleceń. Jednak nieoczekiwanie zmienia to również sposób działania funkcji obsługi ciągów w bibliotece C.

Na przykład, jeśli podczas instalacji Linuksa wybrałeś język „turecki” lub „kazachski”, zauważysz, że wywołanie toupper('i') w celu uzyskania jego odpowiednika pisanego wielkimi literami spowoduje uzyskanie kropkowanej litery I (U+0130, I ).

PHP 8.0 zatrzymał tę anomalię, ustawiając domyślną lokalizację na „C”, chyba że użytkownik wyraźnie ją zmieni za pomocą setlocale() .

PHP 8.2 idzie jeszcze dalej, usuwając wrażliwość na ustawienia regionalne z konwersji wielkości liter. Ten dokument RFC zmienia przede wszystkim strtolower() , strtoupper() i powiązane funkcje. Przeczytaj RFC, aby uzyskać listę wszystkich funkcji, których dotyczy problem.

Alternatywnie, jeśli chcesz użyć zlokalizowanej konwersji wielkości liter, możesz użyć mb_strtolower() .

Ulepszenie losowego rozszerzenia

PHP planuje przebudować swoją losową funkcjonalność.

W tej chwili losowa funkcjonalność PHP w dużej mierze opiera się na stanie Mersenne Twister. Jednak ten stan jest niejawnie przechowywany w globalnym obszarze PHP — użytkownik nie ma do niego dostępu. Dodanie funkcji randomizacji między początkowym etapem inicjowania a zamierzonym użyciem złamałoby kod.

Utrzymanie takiego kodu może być jeszcze bardziej skomplikowane, gdy Twój kod korzysta z zewnętrznych pakietów.

Tak więc obecna funkcjonalność PHP w zakresie losowości nie może konsekwentnie odtwarzać losowych wartości. Nie przechodzi nawet empirycznych testów statystycznych jednolitych generatorów liczb losowych, takich jak Crush i BigCrush TestU01. 32-bitowe ograniczenie Mersenne Twister jeszcze bardziej to pogarsza.

Dlatego używanie wbudowanych funkcji PHP — shuffle() , str_shuffle() , array_rand() — nie jest zalecane, jeśli potrzebujesz kryptograficznie bezpiecznych liczb losowych. W takich przypadkach będziesz musiał zaimplementować nową funkcję za pomocą random_int() lub podobnych funkcji.

Jednak po rozpoczęciu głosowania pojawiło się kilka kwestii związanych z tym RFC. Ta porażka zmusiła zespół PHP do odnotowania wszystkich problemów w osobnym RFC, z opcją głosowania stworzoną dla każdego problemu. Zdecydują się na dalszy ruch dopiero po osiągnięciu konsensusu.

Dodatkowe RFC w PHP 8.2

PHP 8.2 zawiera również wiele nowych funkcji i drobnych zmian. Wymienimy je poniżej wraz z linkami do dodatkowych zasobów:

1. Nowa funkcja curl_upkeep : PHP 8.2 dodaje tę nową funkcję do rozszerzenia Curl. Wywołuje funkcję curl_easy_upkeep() w libcurl, podstawowej bibliotece C, której używa rozszerzenie PHP Curl.
2. Nowa funkcja ini_parse_quantity : dyrektywy PHP INI akceptują rozmiary danych z sufiksem mnożnika. Na przykład możesz zapisać 25 megabajtów jako 25M lub 42 gigabajty jako tylko 42G . Te przyrostki są powszechne w plikach PHP INI, ale są rzadkością gdzie indziej. Ta nowa funkcja analizuje wartości PHP INI i zwraca ich rozmiar danych w bajtach.
3. Nowa funkcja memory_reset_peak_usage : Ta funkcja resetuje szczytowe użycie pamięci zwracane przez funkcję memory_get_peak_usage . Może to być przydatne, gdy wykonujesz tę samą akcję wiele razy i chcesz rejestrować szczytowe użycie pamięci w każdym przebiegu.
4. Obsługa modyfikatora braku przechwytywania ( /n ) w preg_* : W wyrażeniu regularnym metaznaki () wskazują grupę przechwytywania. Oznacza to, że zwracane są wszystkie dopasowania wyrażenia w nawiasie. PHP 8.2 dodaje modyfikator no-capture ( /n ), aby zatrzymać to zachowanie.
5. Spraw, aby rodzina iterator_*() akceptowała wszystkie iterowalne: Od teraz rodzina iterator_*() PHP akceptuje tylko \Traversables (tzn. nie są dozwolone zwykłe tablice). To niepotrzebnie ograniczające, a ten RFC to naprawia.

Streszczenie

PHP 8.2 opiera się na ogromnych ulepszeniach PHP 8.0 i PHP 8.1, co nie jest łatwym zadaniem. Uważamy, że najbardziej ekscytującymi funkcjami PHP 8.2 są nowe, samodzielne typy, właściwości tylko do odczytu i liczne ulepszenia wydajności.

Nie możemy się doczekać, aby przetestować PHP 8.2 z różnymi frameworkami PHP i CMS-ami.

Upewnij się, że dodałeś ten post na blogu do zakładek, aby móc z niego skorzystać w przyszłości.

Które funkcje PHP 8.2 są Twoimi ulubionymi? Które deprecjacje są twoimi najmniej ulubionymi? Podziel się swoimi przemyśleniami z naszą społecznością w komentarzach!