Qué hay de nuevo en PHP 8.2: nuevas características, obsolescencias, cambios y más

PHP 8.2 se basa en la base renovada establecida por PHP 8.0 y PHP 8.1. Su lanzamiento está previsto para el 24 de noviembre de 2022.

Este artículo cubrirá las novedades de PHP 8.2 en detalle: desde sus nuevas funciones y mejoras hasta las obsolescencias y los cambios menores, los repasaremos todos.

Como PHP 8.2 entró en congelación de funciones el 19 de julio de 2022, no puede esperar adiciones significativas a esta lista.

¿Entusiasmado? nosotros también

¡Vamos a empezar!

Nuevas funciones y mejoras en PHP 8.2

Comencemos explorando todas las características más recientes de PHP 8.2. Es una lista bastante extensa:

Nuevas clases readonly

PHP 8.1 introdujo la función de readonly para las propiedades de clase. Ahora, PHP 8.2 está agregando soporte para declarar toda la clase como de readonly .

Si declara una clase como de readonly , todas sus propiedades heredarán automáticamente la característica de readonly . Por lo tanto, declarar una clase de readonly es lo mismo que declarar cada propiedad de clase como de readonly .

Por ejemplo, con PHP 8.1, tenía que escribir este tedioso código para declarar todas las propiedades de clase como de readonly :

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

Imagina lo mismo con muchas más propiedades. Ahora, con PHP 8.2, puedes escribir esto:

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

También puede declarar clases abstractas o finales como de readonly . Aquí, el orden de las palabras clave no importa.

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

También puede declarar una clase de readonly sin propiedades. Efectivamente, esto evita las propiedades dinámicas al mismo tiempo que permite que las clases secundarias declaren explícitamente sus propiedades de readonly .

A continuación, las clases de solo readonly solo pueden contener propiedades escritas: la misma regla para declarar propiedades individuales de solo lectura .

Puede usar la propiedad de tipo mixed si no puede declarar una propiedad de tipo estricto.

Intentar declarar una clase de readonly sin una propiedad escrita dará como resultado un error fatal:

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

Además, no puede declarar readonly para ciertas características de PHP:

• Enumeraciones (ya que no pueden contener ninguna propiedad)
• Rasgos
• Interfaces

Si intenta declarar cualquiera de estas funciones como de readonly , se producirá un error de Parse.

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

Como es el caso de todas las palabras clave de PHP, la palabra clave de readonly distingue entre mayúsculas y minúsculas.

PHP 8.2 también desaprueba las propiedades dinámicas (más sobre eso más adelante). Pero no puede evitar que se agreguen propiedades dinámicas a una clase. Sin embargo, hacerlo para una clase de solo readonly solo generará un error fatal.

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

Permitir true , false y null como tipos independientes

PHP ya incluye tipos escalares como int , string y bool . Eso se amplió en PHP 8.0 con la adición de tipos de unión, lo que permite que los valores sean de diferentes tipos. El mismo RFC también permitía usar false y null como parte de un tipo de unión; sin embargo, no se permitían como tipos independientes.

Si intentó declarar false o null o como tipos independientes, sin que fueran parte de un tipo de unión, resultó en un error 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 ...

Para evitar este escenario, PHP 8.2 está agregando soporte para usar false y null como tipos independientes. Con esta adición, el sistema de tipos de PHP es más expresivo y completo. Ahora puede declarar los tipos de devolución, parámetro y propiedad con precisión.

Además, PHP aún no incluye un tipo true , que parece ser una contrapartida natural del tipo false . PHP 8.2 corrige eso y agrega soporte para el tipo true también. No permite la coerción, exactamente como se comporta el tipo false .

Tanto los tipos true como false son esencialmente un tipo de unión del tipo bool de PHP. Para evitar la redundancia, no puede declarar estos tres tipos juntos en un tipo de unión. Si lo hace, se producirá un error fatal en tiempo de compilación.

Tipos de forma normal disyuntiva (DNF)

La forma normal disyuntiva (DNF) es una forma estandarizada de organizar expresiones booleanas. Consiste en una disyunción de conjunciones; en términos booleanos, eso es un OR de AND .

La aplicación de DNF a las declaraciones de tipo permite una forma estándar de escribir tipos combinados de Unión e Intersección que el analizador puede manejar. La nueva función de tipos DNF de PHP 8.2 es simple pero poderosa si se usa correctamente.

El RFC da el siguiente ejemplo. Supone que ya existen las siguientes definiciones de clase e interfaz:

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

Con los tipos DNF, puede realizar declaraciones de tipos para propiedades, parámetros y valores devueltos de la siguiente manera:

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

En algunos casos, las propiedades pueden no estar en formularios DNF. Declararlos como tales resultará en un error de análisis. Pero siempre puedes reescribirlos como:

 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

Debe tener en cuenta que cada segmento de un tipo DNF debe ser único. Por ejemplo, declarar (A&B)|(B&A) no es válido ya que los dos segmentos OR ed son lógicamente iguales.

Además de esto, los segmentos que son subconjuntos estrictos del otro segmento tampoco están permitidos. Esto se debe a que el superconjunto ya tendrá todas las instancias del subconjunto, por lo que es redundante usar DNF.

Redactar parámetros confidenciales en seguimientos anteriores

Como casi cualquier lenguaje de programación, PHP permite rastrear su pila de llamadas en cualquier punto de la ejecución del código. El seguimiento de la pila facilita la depuración del código para corregir errores y cuellos de botella en el rendimiento. Forma la columna vertebral de herramientas como Kinsta APM, nuestra herramienta de monitoreo de rendimiento diseñada a medida para sitios de WordPress.

Realizar un seguimiento de la pila no detiene la ejecución del programa. Por lo general, la mayoría de los seguimientos de pila se ejecutan en segundo plano y se registran en silencio, para una inspección posterior si es necesario.

Sin embargo, algunos de estos seguimientos detallados de la pila de PHP pueden ser un inconveniente si los comparte con servicios de terceros, generalmente para análisis de registro de errores, seguimiento de errores, etc. Estos seguimientos de la pila pueden incluir información confidencial, como nombres de usuario, contraseñas y variables de entorno. .

Esta propuesta de RFC da un ejemplo de este tipo:

Un "infractor" común es PDO, que toma la contraseña de la base de datos como parámetro del constructor e inmediatamente intenta conectarse a la base de datos dentro del constructor, en lugar de tener un constructor puro y un método ->connect() separado . Por lo tanto, cuando falla la conexión de la base de datos, el seguimiento de la pila incluirá la contraseña de la base de datos:

 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 le permite marcar dichos parámetros sensibles con un nuevo atributo \SensitiveParameter . Cualquier parámetro marcado como confidencial no se incluirá en sus registros. Por lo tanto, puede compartirlos sin preocupaciones con ningún servicio de terceros.

Aquí hay un ejemplo sencillo con un solo parámetro sensible:

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

Cuando genera un seguimiento inverso, cualquier parámetro con el atributo \SensitiveParameter se reemplazará con un objeto \SensitiveParameterValue y su valor real nunca se almacenará en el seguimiento. El objeto SensitiveParameterValue encapsula el valor real del parámetro, si lo necesita por algún motivo.

Nueva función mysqli_execute_query y método mysqli::execute_query

¿Alguna vez ha utilizado la función mysqli_query() con valores de usuario que escapan peligrosamente solo para ejecutar una consulta MySQLi parametrizada?

PHP 8.2 facilita la ejecución de consultas MySQLi parametrizadas con la nueva mysqli_execute_query($sql, $params) y el método mysqli::execute_query .

Esencialmente, esta nueva función es una combinación de mysqli_prepare() , mysqli_execute() y mysqli_stmt_get_result() . Con él, la consulta MySQLi se preparará, vinculará (si pasa algún parámetro) y se ejecutará dentro de la función misma. Si la consulta se ejecuta correctamente, devolverá un objeto mysqli_result . Si no tiene éxito, devolverá false .

La propuesta de RFC da un ejemplo simple pero poderoso:

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

Obtener propiedades de enum en expresiones const

Este RFC propone permitir que el operador ->/?-> enum propiedades de enumeración en expresiones const .

La razón principal de esta nueva función es que no puede usar objetos de enum en algunos lugares, como claves de matriz. En tal caso, tendrá que repetir el valor del caso de enum solo para usarlo.

Permitir la obtención de propiedades de enum en lugares donde los objetos de enum no están permitidos puede simplificar este procedimiento.

Significa que el siguiente código ahora es válido:

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

Y solo para estar seguro, este RFC también incluye soporte para el operador nullsafe ?-> .

Permitir constantes en rasgos

PHP incluye una forma de reutilizar código llamada Traits. Son geniales para la reutilización de código entre clases.

Actualmente, los Traits solo permiten definir métodos y propiedades, pero no constantes. Eso significa que no puede definir las invariantes esperadas por un Rasgo dentro del Rasgo mismo. Para evitar esta limitación, debe definir constantes en su clase de composición o una interfaz implementada por su clase de composición.

Este RFC propone permitir definir constantes en Traits. Estas constantes se pueden definir de la misma manera que definiría las constantes de clase. Este ejemplo tomado directamente del RFC aclara el aire en torno a su uso:

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

Las constantes de Trait también se fusionan en la definición de la clase que las compone, al igual que las definiciones de métodos y propiedades de Trait. También tienen restricciones similares a las propiedades de los Rasgos. Como se señaló en el RFC, esta propuesta, aunque es un buen comienzo, necesita más trabajo para desarrollar la función.

Obsolescencias en PHP 8.2

Ahora podemos pasar a explorar todas las obsolescencias en PHP 8.2. Esta lista no es tan grande como sus nuevas funciones:

Dejar obsoletas las propiedades dinámicas (y el nuevo atributo #[AllowDynamicProperties] )

Hasta PHP 8.1, podía establecer y recuperar dinámicamente propiedades de clase no declaradas en PHP. Por ejemplo:

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

Aquí, la clase Post no declara una propiedad de name . Pero debido a que PHP permite propiedades dinámicas, puede configurarlo fuera de la declaración de clase. Esa es su mayor ventaja, y posiblemente la única.

Las propiedades dinámicas permiten que surjan errores y comportamientos inesperados en su código. Por ejemplo, si comete algún error al declarar una propiedad de clase fuera de la clase, es fácil perderle el rastro, especialmente al depurar cualquier error dentro de esa clase.

Desde PHP 8.2 en adelante, las propiedades dinámicas están obsoletas. Establecer un valor para una propiedad de clase no declarada emitirá un aviso de desaprobación la primera vez que se establezca la propiedad.

 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;

Sin embargo, desde PHP 9.0 en adelante, configurar lo mismo arrojará un error ErrorException .

Si su código está lleno de propiedades dinámicas (y hay mucho código PHP) y desea detener estos avisos de obsolescencia después de actualizar a PHP 8.2, puede usar el nuevo atributo #[AllowDynamicProperties] de PHP 8.2 para permitir propiedades en las clases.

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

Según el RFC, las clases marcadas como #[AllowDynamicProperties] , así como sus clases secundarias, pueden continuar usando propiedades dinámicas sin desaprobación ni eliminación.

También debe tener en cuenta que, en PHP 8.2, la única clase empaquetada marcada como #[AllowDynamicProperties] es stdClass . Además, las propiedades a las que se accede a través de los métodos mágicos de PHP __get() o __set() no se consideran propiedades dinámicas, por lo que no generarán un aviso de obsolescencia.

Dejar en desuso los recursos llamables parcialmente admitidos

Otro cambio de PHP 8.2, aunque con un impacto más insignificante, es desaprobar los callables parcialmente soportados.

Estos callables se denominan parcialmente admitidos porque no puede interactuar con ellos directamente a través $callable() . Solo puede llegar a ellos con la call_user_func($callable) . La lista de tales llamadas no es larga:

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

Desde PHP 8.2 en adelante, cualquier intento de invocar dichas llamadas, como a través de call_user_func() o array_map() , generará una advertencia de desuso.

El RFC original da un razonamiento sólido detrás de esta desaprobación:

Aparte de los dos últimos casos, todos estos callables dependen del contexto. El método al que se refiere "self::method" depende de la clase desde la que se realiza la llamada o la verificación de capacidad de llamada. En la práctica, esto suele ser válido también para los dos últimos casos, cuando se usa en la forma de [new Foo, "parent::method"] .

Reducir la dependencia del contexto de los invocables es el objetivo secundario de este RFC. Después de este RFC, la única dependencia del alcance que queda es la visibilidad del método: "Foo::bar" puede ser visible en un alcance, pero no en otro. Si las llamadas se limitaran a métodos públicos en el futuro (mientras que los métodos privados tendrían que usar llamadas de primera clase o Closure::fromCallable() para ser independientes del alcance), entonces el tipo de llamada estaría bien definido y podría utilizarse como un tipo de propiedad. Sin embargo, los cambios en el manejo de la visibilidad no se proponen como parte de este RFC .

Según el RFC original, la función is_callable() y el tipo callable seguirán aceptando estos invocables como excepciones. Pero solo hasta que el soporte para ellos se elimine por completo de PHP 9.0 en adelante.

Para evitar confusiones, el alcance de este aviso de obsolescencia se amplió con un nuevo RFC; ahora incluye estas excepciones.

Es bueno ver que PHP avanza hacia tener un tipo callable bien definido.

#utf8_encode() y utf8_decode()

Las funciones integradas de PHP utf8_encode() y utf8_decode() convierten cadenas codificadas en ISO-8859-1 ("Latin 1") hacia y desde UTF-8.

Sin embargo, sus nombres sugieren un uso más general de lo que permite su implementación. La codificación "Latin 1" se confunde comúnmente con otras codificaciones como la "página de códigos 1252 de Windows".

Además, normalmente verá Mojibake cuando estas funciones no pueden convertir ninguna cadena correctamente. La falta de mensajes de error también significa que es difícil detectarlos, especialmente dentro de un mar de texto legible.

PHP 8.2 desaprueba las #utf8_encode() y utf8_decode() . Si los invoca, verá estos avisos de obsolescencia:

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

El RFC sugiere usar extensiones compatibles con PHP como mbstring , iconv e intl en su lugar.

Obsoleta la interpolación de cadenas ${}

PHP permite incrustar variables en cadenas con comillas dobles ( " ) y heredoc ( <<< ) de varias maneras:

1. Incrustación directa de variables — “$foo”
2. Con llaves fuera de la variable — “{$foo}”
3. Con llaves después del signo de dólar: “${foo}”
4. Variables variables — “${expr}” — equivalente a usar (string) ${expr}

Las dos primeras formas tienen sus pros y sus contras, mientras que las dos últimas tienen una sintaxis compleja y contradictoria. PHP 8.2 desaprueba las dos últimas formas de interpolación de cadenas.

Debe evitar interpolar cadenas de esta manera en el futuro:

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

A partir de PHP 9.0, estas obsolescencias se actualizarán para generar un error de excepción.

Desactivar funciones mbstring para entidades Base64/QPrint/Uuencode/HTML

Las funciones mbstring (cadena de múltiples bytes) de PHP nos ayudan a trabajar con Unicode, entidades HTML y otras codificaciones de texto heredadas.

Sin embargo, Base64, Uuencode y QPrint no son codificaciones de texto y aún forman parte de estas funciones, principalmente debido a razones heredadas. PHP también incluye implementaciones separadas de estas codificaciones.

En cuanto a las entidades HTML, PHP tiene funciones integradas, htmlspecialchars() y htmlentities() , para manejarlas mejor. Por ejemplo, a diferencia de mbstring, estas funciones también convertirán < . > , y & caracteres a entidades HTML.

Además, PHP siempre está mejorando sus funciones integradas, al igual que PHP 8.1 con funciones de codificación y decodificación de HTML.

Entonces, teniendo todo eso en mente, PHP 8.2 está desaprobando el uso de mbstring para estas codificaciones (las etiquetas no distinguen entre mayúsculas y minúsculas):

• BASE64
• UUENCODIGO
• ENTIDADES HTML
• html (alias de HTML-ENTIDADES)
• Citado imprimible
• qprint (alias de Quoted-Printable)

Desde PHP 8.2 en adelante, el uso de mbstring para codificar/decodificar cualquiera de los anteriores generará un aviso de desaprobación. PHP 9.0 eliminará por completo la compatibilidad con mbstring para estas codificaciones.

Otros cambios menores en PHP 8.2

Finalmente, podemos discutir los cambios menores de PHP 8.2, incluidas las características y funcionalidades eliminadas.

Eliminar el soporte para libmysql de mysqli

A partir de ahora, PHP permite que los controladores mysqli y PDO_mysql se compilen con las bibliotecas mysqlnd y libmysql . Sin embargo, el controlador predeterminado y recomendado desde PHP 5.4 ha sido mysqlnd .

Ambos controladores tienen muchas ventajas y desventajas. Sin embargo, eliminar el soporte para uno de ellos (idealmente, eliminar libmysql ya que no es el predeterminado) simplificará el código de PHP y las pruebas unitarias.

Para argumentar a favor de este favor, el RFC enumera muchas ventajas de mysqlnd :

• Está incluido con PHP
• Utiliza la gestión de memoria PHP para monitorear el uso de la memoria y
  mejorar el rendimiento
• Proporciona funciones de calidad de vida (por ejemplo get_result() )
• Devuelve valores numéricos usando tipos nativos de PHP
• Su funcionalidad no depende de la biblioteca externa
• Funcionalidad de complemento opcional
• Admite consultas asíncronas

El RFC también enumera algunas ventajas de libmysql , que incluyen:

• La reconexión automática es posible ( mysqlnd no admite esta funcionalidad intencionalmente porque puede explotarse fácilmente)
• Modos de autenticación LDAP y SASL ( mysqlnd puede agregar esta función pronto)

Además, el RFC enumera muchas desventajas de libmysql : incompatibilidad con el modelo de memoria PHP, muchas pruebas fallidas, fugas de memoria, diferentes funcionalidades entre versiones, etc.

Teniendo todo esto en cuenta, PHP 8.2 eliminó el soporte para construir mysqli contra libmysql .

Si desea agregar cualquier funcionalidad que solo esté disponible con libmysql , deberá agregarla explícitamente a mysqlnd como una solicitud de función. Además, no puede agregar la reconexión automática.

Conversión de mayúsculas y minúsculas independiente de la configuración regional

Antes de PHP 8.0, la configuración regional de PHP se heredaba del entorno del sistema. Pero esto podría causar un problema en algunos casos extremos.

Configurar su idioma durante la instalación de Linux establecerá el idioma de interfaz de usuario apropiado para sus comandos integrados. Sin embargo, también cambia inesperadamente cómo funciona la funcionalidad de manejo de cadenas de la biblioteca C.

Por ejemplo, si seleccionó el idioma "turco" o "kazajo" al instalar Linux, encontrará que llamar a toupper('i') para obtener su equivalente en mayúsculas obtendría la I mayúscula punteada (U+0130, I ).

PHP 8.0 detuvo esta anomalía al establecer la configuración regional predeterminada en "C", a menos que el usuario la cambie explícitamente a través de setlocale() .

PHP 8.2 va aún más lejos al eliminar la sensibilidad de configuración regional de las conversiones de mayúsculas y minúsculas. Este RFC cambia principalmente strtolower() , strtoupper() y funciones relacionadas. Lea el RFC para obtener una lista de todas las funciones afectadas.

Como alternativa, si desea utilizar la conversión de mayúsculas y minúsculas localizada, puede utilizar mb_strtolower() .

Mejora de extensión aleatoria

PHP planea revisar su funcionalidad aleatoria.

A partir de ahora, la funcionalidad aleatoria de PHP se basa en gran medida en el estado de Mersenne Twister. Sin embargo, este estado se almacena implícitamente en el área global de PHP; no hay forma de que un usuario pueda acceder a él. Agregar funciones de aleatorización entre la etapa de siembra inicial y el uso previsto rompería el código.

Mantener dicho código puede ser aún más complicado cuando su código usa paquetes externos.

Por lo tanto, la funcionalidad aleatoria actual de PHP no puede reproducir valores aleatorios de manera consistente. Incluso falla en las pruebas estadísticas empíricas de generadores de números aleatorios uniformes, como Crush y BigCrush de TestU01. La limitación de 32 bits de Mersenne Twister lo agrava aún más.

Por lo tanto, no se recomienda usar las funciones integradas de PHP shuffle() , str_shuffle() , array_rand() si necesita números aleatorios criptográficamente seguros. En tales casos, deberá implementar una nueva función usando random_int() o funciones similares.

Sin embargo, se plantearon varios problemas con este RFC después de que comenzó la votación. Este contratiempo obligó al equipo de PHP a anotar todos los problemas en un RFC separado, con una opción de votación creada para cada problema. Decidirán avanzar más solo después de llegar a un consenso.

RFC adicionales en PHP 8.2

PHP 8.2 también incluye muchas funciones nuevas y cambios menores. Los mencionaremos a continuación con enlaces a recursos adicionales:

1. Nueva función curl_upkeep : PHP 8.2 agrega esta nueva función a su extensión Curl. Llama a la función curl_easy_upkeep() en libcurl, la biblioteca C subyacente que usa la extensión PHP Curl.
2. Nueva función ini_parse_quantity : las directivas PHP INI aceptan tamaños de datos con un sufijo multiplicador. Por ejemplo, puede escribir 25 Megabytes como 25M o 42 Gigabytes como 42G . Estos sufijos son comunes en los archivos INI de PHP, pero no son comunes en otros lugares. Esta nueva función analiza los valores PHP INI y devuelve su tamaño de datos en bytes.
3. Nueva función memory_reset_peak_usage : esta función restablece el uso máximo de memoria devuelto por la función memory_get_peak_usage . Puede ser útil cuando ejecuta la misma acción varias veces y desea registrar el uso máximo de memoria de cada ejecución.
4. Compatibilidad con el modificador sin captura ( /n ) en funciones preg_* : en expresiones regulares, los metacaracteres () indican un grupo de captura. Eso significa que se devuelven todas las coincidencias para la expresión dentro del paréntesis. PHP 8.2 agrega un modificador de no captura ( /n ) para detener este comportamiento.
5. Hacer que la familia iterator_*() acepte todos los iterables: A partir de ahora, la familia iterator_*() de PHP solo acepta \Traversables (es decir, no se permiten matrices simples). Es innecesariamente limitante, y este RFC lo soluciona.

Resumen

PHP 8.2 se basa en las mejoras masivas de PHP 8.0 y PHP 8.1, lo cual no es tarea fácil. Creemos que las características más emocionantes de PHP 8.2 son sus nuevos tipos independientes, propiedades de solo lectura y numerosas mejoras de rendimiento.

Estamos ansiosos por comparar PHP 8.2 con varios marcos PHP y CMS.

Asegúrese de marcar esta publicación de blog para su futura referencia.

¿Qué características de PHP 8.2 son tus favoritas? ¿Qué deprecaciones son las que menos te gustan? ¡Por favor comparte tus pensamientos con nuestra comunidad en los comentarios!