Что нового в PHP 8.2 — новые функции, устаревание, изменения и многое другое

PHP 8.2 основан на обновленной базе, изложенной в PHP 8.0 и PHP 8.1. Релиз запланирован на 24 ноября 2022 года.

В этой статье будет подробно рассказано о том, что нового в PHP 8.2 — от его новых функций и улучшений до устаревания и незначительных изменений, мы рассмотрим их все.

Поскольку 19 июля 2022 года PHP 8.2 заморозил свои функции, вы не можете ожидать значительных дополнений к этому списку.

Взволнованный? Мы тоже.

Давайте начнем!

Новые функции и улучшения в PHP 8.2

Давайте начнем с изучения всех последних возможностей PHP 8.2. Это довольно обширный список:

Новые классы readonly

PHP 8.1 представил функцию только для readonly для свойств класса. Теперь в PHP 8.2 добавлена ​​поддержка объявления всего класса только для readonly .

Если вы объявите класс доступным только для readonly , все его свойства автоматически наследуют функцию только для readonly . Таким образом, объявление класса только для readonly — это то же самое, что объявление каждого свойства класса только для readonly .

Например, в PHP 8.1 вам пришлось написать этот утомительный код, чтобы объявить все свойства класса доступными только для readonly :

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

Представьте себе то же самое со многими другими свойствами. Теперь, с PHP 8.2, вы можете просто написать это:

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

Вы также можете объявить абстрактные или окончательные классы только для readonly . Здесь порядок ключевых слов не имеет значения.

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

Вы также можете объявить класс только для readonly без свойств. По сути, это предотвращает динамические свойства, но позволяет дочерним классам явно объявлять свои свойства только для readonly .

Далее, классы только для readonly могут содержать только типизированные свойства — то же правило для объявления отдельных свойств только для чтения .

Вы можете использовать свойство mixed типа, если вы не можете объявить строго типизированное свойство.

Попытка объявить класс только для readonly без типизированного свойства приведет к фатальной ошибке:

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

Кроме того, вы не можете объявить readonly для некоторых функций PHP:

• Перечисления (поскольку они не могут содержать никаких свойств)
• Черты
• Интерфейсы

Попытка объявить любую из этих функций доступной только для readonly приведет к ошибке Parse.

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

Как и в случае со всеми ключевыми словами PHP, ключевое слово readonly нечувствительно к регистру.

PHP 8.2 также не поддерживает динамические свойства (подробнее об этом позже). Но вы не можете предотвратить добавление динамических свойств в класс. Однако выполнение этого для класса только для readonly приведет только к фатальной ошибке.

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

Разрешить true , false и null в качестве автономных типов

PHP уже включает скалярные типы, такие как int , string и bool . Это было расширено в PHP 8.0 с добавлением типов объединения, позволяющих значениям быть разных типов. Тот же RFC также разрешал использовать false и null как часть типа объединения — однако они не допускались как отдельные типы.

Если вы попытались объявить false или null или как автономные типы — без того, чтобы они были частью типа объединения — это привело к фатальной ошибке.

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

Чтобы избежать этого сценария, в PHP 8.2 добавлена ​​поддержка использования false и null в качестве автономных типов. Благодаря этому дополнению система типов PHP стала более выразительной и полной. Теперь вы можете точно объявить типы возврата, параметра и свойства.

Кроме того, в PHP до сих пор нет true типа, который кажется естественным аналогом false типа. В PHP 8.2 это исправлено, а также добавлена ​​поддержка true типа. Он не допускает принуждения, точно так же, как ведет себя false тип.

И true , и false типы по существу являются типом объединения типа bool в PHP. Чтобы избежать избыточности, вы не можете объявить эти три типа вместе в типе объединения. Это приведет к фатальной ошибке времени компиляции.

Типы дизъюнктивной нормальной формы (ДНФ)

Дизъюнктивная нормальная форма (ДНФ) — это стандартизированный способ организации логических выражений. Он состоит из дизъюнкции союзов — в логических терминах это ИЛИ из И.

Применение DNF к объявлениям типов позволяет стандартным способом писать комбинированные типы Union и Intersection, которые может обрабатывать синтаксический анализатор. Новая функция типов DNF в PHP 8.2 проста, но эффективна при правильном использовании.

В RFC приводится следующий пример. Предполагается, что следующие определения интерфейса и класса уже существуют:

 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 вы можете выполнять объявления типов для свойств, параметров и возвращаемых значений следующим образом:

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

В некоторых случаях свойства могут не быть в формах DNF. Объявление их как таковых приведет к ошибке синтаксического анализа. Но вы всегда можете переписать их как:

 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

Следует отметить, что каждый сегмент типа DNF должен быть уникальным. Например, объявление (A&B)|(B&A) недопустимо, поскольку два сегмента, соединенные по ИЛИ , логически одинаковы.

Кроме того, сегменты, которые являются строгими подмножествами другого сегмента, также не допускаются. Это связано с тем, что надмножество уже будет иметь все экземпляры подмножества, что делает излишним использование DNF.

Редактировать конфиденциальные параметры в обратных трассировках

Как почти любой язык программирования, PHP позволяет отслеживать свой стек вызовов в любой момент выполнения кода. Трассировка стека упрощает отладку кода для исправления ошибок и узких мест производительности. Он составляет основу таких инструментов, как Kinsta APM, нашего специально разработанного инструмента мониторинга производительности для сайтов WordPress.

Выполнение трассировки стека не останавливает выполнение программы. Как правило, большинство трассировок стека выполняются в фоновом режиме и регистрируются в журнале автоматически — для последующей проверки при необходимости.

Однако некоторые из этих подробных трассировок стека PHP могут быть недостатком, если вы делитесь ими со сторонними службами — обычно для анализа журнала ошибок, отслеживания ошибок и т. д. Эти трассировки стека могут включать конфиденциальную информацию, такую ​​как имена пользователей, пароли и переменные среды. .

Это предложение RFC дает один такой пример:

Одним из распространенных «нарушителей» является PDO, который принимает пароль базы данных в качестве параметра конструктора и немедленно пытается подключиться к базе данных внутри конструктора вместо чистого конструктора и отдельного метода ->connect() . Таким образом, при сбое подключения к базе данных трассировка стека будет включать пароль базы данных:

 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 позволяет помечать такие конфиденциальные параметры новым атрибутом \SensitiveParameter . Любой параметр, помеченный как конфиденциальный, не будет указан в ваших обратных трассировках. Таким образом, вы можете без опасений делиться ими со сторонними сервисами.

Вот простой пример с одним конфиденциальным параметром:

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

При создании трассировки любой параметр с атрибутом \SensitiveParameter будет заменен объектом \SensitiveParameterValue , и его реальное значение никогда не будет сохранено в трассировке. Объект SensitiveParameterValue инкапсулирует фактическое значение параметра, если оно вам нужно по какой-либо причине.

Новая функция mysqli_execute_query и метод mysqli::execute_query

Вы когда-нибудь использовали mysqli_query() с опасным экранированием пользовательских значений только для запуска параметризованного запроса MySQLi?

PHP 8.2 упрощает выполнение параметризованных запросов MySQLi благодаря новой mysqli_execute_query($sql, $params) и методу mysqli::execute_query .

По сути, эта новая функция представляет собой комбинацию функций mysqli_prepare() , mysqli_execute() и mysqli_stmt_get_result() . С его помощью запрос MySQLi будет подготовлен, связан (если вы передадите какие-либо параметры) и выполнен внутри самой функции. Если запрос выполняется успешно, он возвращает объект mysqli_result . В случае неудачи он вернет false .

Предложение RFC дает простой, но мощный пример:

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

Получить свойства enum в const выражениях

В этом RFC предлагается разрешить оператору ->/?-> извлекать свойства enum в const выражениях.

Основная причина этой новой функции заключается в том, что в некоторых местах нельзя использовать enum объекты, например ключи массива. В таком случае вам придется повторить значение регистра enum , чтобы использовать его.

Разрешение извлечения свойств enum в местах, где объекты enum не разрешены, может упростить эту процедуру.

Это означает, что следующий код теперь действителен:

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

И на всякий случай этот RFC также включает поддержку оператора nullsafe ?-> .

Разрешить константы в свойствах

PHP включает способ повторного использования кода, который называется Traits. Они отлично подходят для повторного использования кода в разных классах.

В настоящее время Traits позволяют определять только методы и свойства, но не константы. Это означает, что вы не можете определить инварианты, ожидаемые Чертой, внутри самой Черты. Чтобы обойти это ограничение, вам необходимо определить константы в его составляющем классе или интерфейсе, реализованном в его составляющем классе.

Этот RFC предлагает разрешить определение констант в свойствах. Эти константы могут быть определены так же, как вы определяете константы класса. Этот пример, взятый прямо из RFC, проясняет ситуацию вокруг его использования:

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

Константы трейтов также объединяются в определение составного класса, так же, как определения свойств и методов трейтов. У них также есть такие же ограничения, как и у свойств Traits. Как отмечается в RFC, это предложение — хотя и является хорошим началом — нуждается в дальнейшей доработке, чтобы конкретизировать эту функцию.

Устаревшие в PHP 8.2

Теперь мы можем перейти к изучению всех устаревших версий PHP 8.2. Этот список не так велик, как его новые функции:

Устаревшие динамические свойства (и новый #[AllowDynamicProperties] )

Вплоть до PHP 8.1 вы могли динамически устанавливать и извлекать необъявленные свойства класса в PHP. Например:

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

Здесь класс Post не объявляет свойство name . Но поскольку PHP допускает динамические свойства, вы можете установить их вне объявления класса. Это его самое большое — и, возможно, единственное — преимущество.

Динамические свойства позволяют неожиданным ошибкам и поведению возникать в вашем коде. Например, если вы допустили какую-либо ошибку при объявлении свойства класса за пределами класса, ее легко потерять, особенно при отладке любых ошибок внутри этого класса.

Начиная с PHP 8.2, динамические свойства устарели. Установка значения для необъявленного свойства класса будет выдавать уведомление об устаревании при первой установке свойства.

 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;

Однако, начиная с PHP 9.0, установка того же значения вызовет ошибку ErrorException .

Если ваш код полон динамических свойств — а таких PHP-кодов много — и если вы хотите прекратить эти уведомления об устаревании после обновления до PHP 8.2, вы можете использовать новый атрибут PHP 8.2 #[AllowDynamicProperties] , чтобы разрешить динамические свойства. свойства на классах.

 #[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, классы, помеченные как #[AllowDynamicProperties] , а также их дочерние классы могут продолжать использовать динамические свойства без устаревания или удаления.

Вы также должны отметить, что в PHP 8.2 единственным связанным классом, отмеченным как #[AllowDynamicProperties] , является stdClass . Кроме того, любые свойства, доступ к которым осуществляется с помощью магических методов PHP __get() или __set() , не считаются динамическими свойствами, поэтому они не вызывают уведомление об устаревании.

Устаревшие частично поддерживаемые вызываемые объекты

Еще одно изменение PHP 8.2, хотя и с более незначительным влиянием, заключается в отказе от частично поддерживаемых вызываемых объектов.

Эти callables называются частично поддерживаемыми, потому что вы не можете взаимодействовать с ними напрямую через $callable() . Вы можете добраться до них только с помощью функции call_user_func($callable) . Список таких callables невелик:

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

Начиная с PHP 8.2 и далее, любые попытки вызвать такие вызываемые объекты — например, через call_user_func() или array_map() — будут выдавать предупреждение об устаревании.

Оригинальный RFC дает веские доводы в пользу этого устаревания:

За исключением последних двух случаев, все эти вызываемые объекты зависят от контекста. Метод, на который ссылается "self::method" , зависит от того, из какого класса выполняется вызов или проверка возможности вызова. На практике это обычно справедливо и для последних двух случаев, когда используется в форме [new Foo, "parent::method"] .

Уменьшение зависимости вызываемых объектов от контекста является вторичной целью этого RFC. После этого RFC единственная оставшаяся зависимость от области видимости — это видимость метода: "Foo::bar" может быть виден в одной области видимости, но не в другой. Если бы в будущем вызываемые объекты были ограничены общедоступными методами (в то время как частные методы должны были бы использовать вызываемые объекты первого класса или Closure::fromCallable() , чтобы сделать их независимыми от области видимости), то вызываемый тип стал бы четко определенным и мог бы использоваться как тип свойства. Однако в рамках этого RFC не предлагаются изменения в обработке видимости .

Согласно исходному RFC, is_callable() и callable тип будут продолжать принимать эти вызываемые объекты как исключения. Но только до тех пор, пока их поддержка не будет полностью удалена, начиная с PHP 9.0.

Чтобы избежать путаницы, область этого уведомления об устаревании была расширена новым RFC — теперь он включает эти исключения.

Приятно видеть, что PHP движется к четко определенному callable типу.

Устаревшие #utf8_encode() и utf8_decode()

Встроенные функции utf8_encode() и utf8_decode() преобразуют строки, закодированные в ISO-8859-1 («Latin 1»), в UTF-8 и обратно.

Однако их имена предполагают более широкое использование, чем позволяет их реализация. Кодировку «Latin 1» обычно путают с другими кодировками, такими как «Кодовая страница Windows 1252».

Кроме того, вы обычно увидите Mojibake, когда эти функции не могут правильно преобразовать какую-либо строку. Отсутствие сообщений об ошибках также означает, что их трудно обнаружить, особенно в море разборчивого текста.

В PHP 8.2 обе #utf8_encode() и utf8_decode() . Если вы вызовете их, вы увидите эти уведомления об устаревании:

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

RFC предлагает вместо этого использовать поддерживаемые PHP расширения, такие как mbstring , iconv и intl .

Устаревшая интерполяция строк ${}

PHP позволяет вставлять переменные в строки с двойными кавычками ( " ) и heredoc ( <<< ) несколькими способами:

1. Непосредственное встраивание переменных — “$foo”
2. С фигурными скобками вне переменной — “{$foo}”
3. С фигурными скобками после знака доллара — “${foo}”
4. Переменные переменные — “${expr}” — эквивалентно использованию (string) ${expr}

Первые два способа имеют свои плюсы и минусы, а последние два имеют сложный и противоречивый синтаксис. PHP 8.2 не поддерживает последние два способа интерполяции строк.

Вы должны избегать интерполяции строк таким образом:

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

Начиная с PHP 9.0, эти устаревшие версии будут генерировать ошибку исключения.

Устаревшие функции mbstring для объектов Base64/QPrint/Uuencode/HTML

Функции PHP mbstring (многобайтовая строка) помогают нам работать с Unicode, объектами HTML и другими устаревшими кодировками текста.

Однако Base64, Uuencode и QPrint не являются текстовыми кодировками и по-прежнему являются частью этих функций — в первую очередь из-за устаревших причин. PHP также включает отдельные реализации этих кодировок.

Что касается сущностей HTML, в PHP есть встроенные функции — htmlspecialchars() и htmlentities() — для лучшей работы с ними. Например, в отличие от mbstring, эти функции также преобразуют < . > и символы & для объектов HTML.

Более того, PHP постоянно совершенствует свои встроенные функции — так же, как PHP 8.1 с функциями кодирования и декодирования HTML.

Итак, учитывая все это, PHP 8.2 не рекомендует использовать mbstring для этих кодировок (метки нечувствительны к регистру):

• BASE64
• UUENCODE
• HTML-ОБЪЕКТЫ
• html (псевдоним HTML-ENTITIES)
• Котировки-для печати
• qprint (псевдоним Quoted-Printable)

Начиная с PHP 8.2 и выше, использование mbstring для кодирования/декодирования любого из вышеперечисленного будет выдавать уведомление об устаревании. PHP 9.0 полностью удалит поддержку mbstring для этих кодировок.

Другие незначительные изменения в PHP 8.2

Наконец, мы можем обсудить небольшие изменения в PHP 8.2, в том числе удаленные функции и возможности.

Удалить поддержку libmysql из mysqli

На данный момент PHP позволяет драйверам mysqli и PDO_mysql собирать библиотеки mysqlnd и libmysql . Однако драйвером по умолчанию и рекомендуемым драйвером, начиная с PHP 5.4, был mysqlnd .

Оба эти драйвера имеют много преимуществ и недостатков. Однако удаление поддержки одного из них — в идеале, удаление libmysql , так как он не используется по умолчанию — упростит PHP-код и модульные тесты.

В качестве аргумента в пользу этого преимущества RFC перечисляет множество преимуществ mysqlnd :

• Он связан с PHP
• Он использует управление памятью PHP для мониторинга использования памяти и
  улучшить производительность
• Предоставляет функции качества жизни (например get_result() )
• Возвращает числовые значения, используя собственные типы PHP.
• Его функциональность не зависит от внешней библиотеки
• Дополнительный функционал плагина
• Поддерживает асинхронные запросы

В RFC также перечислены некоторые преимущества libmysql , в том числе:

• Возможно автоматическое повторное подключение ( mysqlnd не поддерживает эту функцию намеренно, потому что ее можно легко использовать)
• Режимы аутентификации LDAP и SASL ( mysqlnd может скоро добавить эту функцию)

Кроме того, в RFC перечислены многие недостатки libmysql — несовместимость с моделью памяти PHP, множество неудачных тестов, утечки памяти, разные функциональные возможности между версиями и т. д.

Учитывая все это, в PHP 8.2 удалена поддержка сборки mysqli против libmysql .

Если вы хотите добавить какую-либо функциональность, доступную только в libmysql , вам придется явно добавить ее в mysqlnd в качестве запроса функции. Также нельзя добавить автопереподключение.

Независимая от локали конвертация регистра

До версии PHP 8.0 локаль PHP наследовалась от системной среды. Но это может вызвать проблемы в некоторых крайних случаях.

Установка языка при установке Linux задаст соответствующий язык пользовательского интерфейса для его встроенных команд. Однако это также неожиданно меняет то, как работает функциональность обработки строк в библиотеке C.

Например, если вы выбрали «турецкий» или «казахский» язык при установке Linux, вы обнаружите, что вызов toupper('i') для получения его эквивалента в верхнем регистре приведет к получению заглавной буквы I (U+0130, I ).

PHP 8.0 предотвратил эту аномалию, установив локаль по умолчанию на «C», если только пользователь не изменит ее явным образом с помощью setlocale() .

PHP 8.2 идет еще дальше, удаляя чувствительность к локали из преобразования регистра. Этот RFC в первую очередь изменяет strtolower() , strtoupper() и связанные с ними функции. Прочтите RFC для получения списка всех затронутых функций.

В качестве альтернативы, если вы хотите использовать локализованное преобразование регистра, вы можете использовать mb_strtolower() .

Улучшение случайного расширения

PHP планирует пересмотреть свою случайную функциональность.

На данный момент случайная функциональность PHP в значительной степени зависит от состояния Mersenne Twister. Однако это состояние неявно сохраняется в глобальной области PHP — пользователь не может получить к нему доступ. Добавление функций рандомизации между начальным этапом заполнения и предполагаемым использованием приведет к поломке кода.

Сопровождение такого кода может быть еще более сложным, если ваш код использует внешние пакеты.

Таким образом, текущая случайная функциональность PHP не может последовательно воспроизводить случайные значения. Он даже не проходит эмпирические статистические тесты однородных генераторов случайных чисел, таких как Crush и BigCrush от TestU01. 32-битное ограничение Mersenne Twister еще больше усугубляет ситуацию.

Таким образом, использование встроенных функций PHP — shuffle() , str_shuffle() , array_rand() — не рекомендуется, если вам нужны криптографически безопасные случайные числа. В таких случаях вам нужно будет реализовать новую функцию, используя random_int() или аналогичные функции.

Однако после начала голосования было поднято несколько вопросов по этому RFC. Эта неудача вынудила команду разработчиков PHP отметить все проблемы в отдельном RFC, при этом для каждой проблемы был создан вариант голосования. Они примут решение двигаться дальше только после достижения консенсуса.

Дополнительные RFC в PHP 8.2

PHP 8.2 также включает множество новых функций и незначительных изменений. Мы упомянем их ниже со ссылками на дополнительные ресурсы:

1. Новая функция curl_upkeep : PHP 8.2 добавляет эту новую функцию в расширение Curl. Он вызывает curl_easy_upkeep() в libcurl, базовой библиотеке C, которую использует расширение PHP Curl.
2. Новая функция ini_parse_quantity : директивы PHP INI принимают размеры данных с суффиксом множителя. Например, вы можете записать 25 мегабайт как 25M или 42 гигабайта как 42G . Эти суффиксы распространены в INI-файлах PHP, но редко встречаются в других местах. Эта новая функция анализирует значения PHP INI и возвращает их размер данных в байтах.
3. Новая функция memory_reset_peak_usage : эта функция сбрасывает пиковое использование памяти, возвращаемое функцией memory_get_peak_usage . Это может быть удобно, когда вы запускаете одно и то же действие несколько раз и хотите записывать пиковое использование памяти при каждом запуске.
4. Поддержка модификатора отсутствия захвата ( /n ) в preg_* : в регулярном выражении метасимволы () указывают на захватываемую группу. Это означает, что возвращаются все совпадения выражения в скобках. PHP 8.2 добавляет модификатор запрета захвата ( /n ), чтобы остановить это поведение.
5. Сделайте так, чтобы семейство iterator_*() принимало все итерируемые объекты: на данный момент семейство PHP iterator_*() принимает только \Traversables (т.е. простые массивы запрещены). Это излишне ограничивает, и этот RFC исправляет это.

Резюме

PHP 8.2 основан на значительных улучшениях в PHP 8.0 и PHP 8.1, что не так просто. Мы считаем, что наиболее интересными функциями PHP 8.2 являются новые автономные типы, свойства только для чтения и многочисленные улучшения производительности.

Нам не терпится сравнить PHP 8.2 с различными PHP-фреймворками и CMS.

Не забудьте добавить этот пост в закладки для дальнейшего использования.

Какие функции PHP 8.2 вам нравятся больше всего? Какие устаревания вам нравятся меньше всего? Пожалуйста, поделитесь своими мыслями с нашим сообществом в комментариях!