PHP 8.2 se ha construido sobre la base renovada establecida por PHP 8.0 y PHP 8.1. Ahora que PHP 8.2 ya está disponible, vamos a analizar en detalle las novedades de PHP 8.2 — desde sus nuevas características y mejoras hasta las depreciaciones y cambios menores.

Como PHP 8.2 entró en su fase de congelación de características el 19 de julio de 2022, no se pueden esperar adiciones significativas a esta lista.

¿Emocionado? Nosotros también.

¡Empecemos!

Nuevas Características y Mejoras en PHP 8.2

Empecemos 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ónreadonly para las propiedades de las clases. Ahora, PHP 8.2 añade soporte para declarar toda la clase como readonly.

Si declaras una clase como readonly, todas sus propiedades heredarán automáticamente la característica readonly. Así, declarar una clase readonly es lo mismo que declarar todas las propiedades de la clase como readonly.

Por ejemplo, con PHP 8.1, tenías que escribir este tedioso código para declarar todas las propiedades de la clase como 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 simplemente esto:

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

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

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

También puedes declarar una clase readonly sin propiedades. En efecto, esto evita las propiedades dinámicas, pero permite que las clases hijas declaren sus propiedades readonly explícitamente.

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

Puedes utilizar la propiedad de tipo mixed si no puedes declarar una propiedad de tipo estricto.

Si intentas declarar una clase readonly sin una propiedad tipificada, se producirá un error fatal:

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

Además, no puedes declarar readonly para ciertas funciones de PHP:

El intento de declarar cualquiera de estas funciones como readonly dará lugar a un error de análisis.

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

Como ocurre con todas las palabras clave de PHP, la palabra clave readonly no distingue entre mayúsculas y minúsculas.

PHP 8.2 también desaprueba las propiedades dinámicas (más adelante se hablará de ello). Pero no puedes impedir que se añadan propiedades dinámicas a una clase. Sin embargo, si lo haces en una clase readonly sólo se producirá 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. Esto se amplió en PHP 8.0 con la adición de tipos de unión, que permiten que los valores sean de diferentes tipos. La misma RFC también permitía utilizar false y null como parte de un tipo de unión, pero no se permitían como tipos independientes.

Si intentabas declarar false o null como tipos independientes — sin que formaran parte de un tipo de unión — se producía 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 esta situación, PHP 8.2 añade soporte para utilizar false y null como tipos independientes. Con esta adición, el sistema de tipos de PHP es más expresivo y completo. Ahora puedes declarar con precisión los tipos de retorno, de parámetro y de propiedad.

Además, PHP sigue sin incluir un tipo true, que parece ser una contrapartida natural del tipo false. PHP 8.2 corrige esto y añade también soporte para el tipo true. No permite la coerción, exactamente como se comporta el tipo false.

Ambos tipos true y false son esencialmente un tipo de unión del tipo bool de PHP. Para evitar la redundancia, no puedes declarar estos tres tipos juntos en un tipo de unión. Si lo haces, 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 las expresiones booleanas. Consiste en una disyunción de conjunciones — en términos booleanos, es un OR de ANDs.

Aplicar DNF a las declaraciones de tipos permite una forma estándar de escribir tipos combinados de Unión e Intersección que el analizador sintáctico puede manejar. La nueva función de tipos DNF de PHP 8.2 es sencilla pero potente si se utiliza correctamente.

La RFC ofrece el siguiente ejemplo. Supone que ya existen las siguientes definiciones de interfaz y de clase:

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, puedes realizar declaraciones de tipo para las propiedades, los parámetros y los valores de retorno 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 formas DNF. Declararlas como tales dará lugar a un error de análisis. Pero siempre puedes reescribirlas 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

Debes 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 son lógicamente iguales.

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

Redactar los Parámetros Confidenciales en las Back Traces

Como casi cualquier lenguaje de programación, PHP permite trazar su stack de llamadas en cualquier punto de la ejecución del stack 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 monitorización del rendimiento diseñada a medida para los sitios de WordPress.

Seguimiento de las transacciones lentas de WooCommerce con Kinsta APM.
Seguimiento de las transacciones lentas de WooCommerce con Kinsta APM.

Realizar un seguimiento del stack no detiene la ejecución del programa. Normalmente, la mayoría de los stack traces se ejecutan en segundo plano y se registran de forma silenciosa, para poder inspeccionarlos posteriormente si es necesario.

Sin embargo, algunas de estas detalladas trazas del stack de PHP pueden ser un inconveniente si las compartes con servicios de terceros, normalmente para el análisis del registro de errores, el seguimiento de errores, etc. Estos stack traces pueden incluir información sensible como nombres de usuario, contraseñas y variables de entorno.

Esta propuesta de RFC ofrece un ejemplo de ello:

Un «infractor» habitual es PDO, que toma la contraseña de la base de datos como parámetro del constructor e intenta conectarse inmediatamente a la base de datos dentro del constructor, en lugar de tener un constructor puro y un método separado ->connect(). Así, cuando la conexión a la base de datos falla, el seguimiento del stack 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 te permite marcar estos parámetros sensibles con un nuevo atributo \SensitiveParameter. Cualquier parámetro marcado como sensible no aparecerá en tus backtraces. Así, puedes compartirlos sin preocupaciones con cualquier servicio de terceros.

He aquí 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 generes un backtrace, cualquier parámetro con el atributo \SensitiveParameter será sustituido por un objeto \SensitiveParameterValue, y su valor real nunca se almacenará en el trazado. El objeto SensitiveParameterValue encapsula el valor real del parámetro, por si lo necesitas por alguna razón.

Nueva Función mysqli_execute_query y Método mysqli::execute_query

¿Has utilizado alguna vez la función mysqli_query() con valores de usuario que escapan peligrosamente sólo para ejecutar una consulta MySQLi parametrizada?

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

Básicamente, esta nueva función es una combinación de las funciones mysqli_prepare(), mysqli_execute() y mysqli_stmt_get_result(). Con ella, la consulta MySQLi se preparará, se vinculará (si pasas algún parámetro) y se ejecutará dentro de la propia función. Si la consulta se ejecuta con éxito, devolverá un objeto mysqli_result. Si no tiene éxito, devolverá false.

La propuesta de RFC ofrece un ejemplo sencillo pero potente:

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

Recuperar Propiedades de enum en Expresiones de const

Esta RFC propone permitir que el operador ->/?-> obtenga enum propiedades en las expresiones const.

La razón principal de esta nueva función es que no puedes utilizar los objetos enum en algunos lugares, como las claves de los arrays. En tal caso, tendrás que repetir el valor del caso enum sólo para utilizarlo.

Permitir la obtención de propiedades enum en lugares donde no se permiten los objetos enum puede simplificar este procedimiento.

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

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

Y para estar seguros, esta RFC también incluye soporte para el operador nullsafe ?->.

Permitir Constantes en los Traits

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

Actualmente, los Traits sólo permiten definir métodos y propiedades, pero no constantes. Eso significa que no puedes definir las invariantes esperadas por un Trait dentro del propio Trait. Para evitar esta limitación, tienes que definir las constantes en su clase de composición o en una interfaz implementada por su clase compuesta.

Esta RFC propone permitir la definición de constantes en los Traits. Estas constantes pueden definirse igual que se definirían las constantes de la clase. Este ejemplo extraído directamente de la RFC aclara 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 los Traits también se integran en la definición de la clase que los compone, al igual que las definiciones de propiedades y métodos de un Trait. También tienen restricciones similares a las de las propiedades de los Traits. Como se indica en la RFC, esta propuesta — aunque es un buen comienzo — necesita más trabajo para concretar la función.

Deprecaciones en PHP 8.2

Ahora podemos pasar a explorar todas las deprecaciones de PHP 8.2. Esta lista no es tan grande como sus nuevas características:

Deprecación de las Propiedades Dinámicas (y el Nuevo Atributo #[AllowDynamicProperties] )

Hasta PHP 8.1, podías 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 name. Pero como PHP permite las propiedades dinámicas, puedes establecerla fuera de la declaración de la clase. Esa es su mayor  — y posiblemente, la única — ventaja.

Las propiedades dinámicas permiten que aparezcan errores y comportamientos inesperados en tu código. Por ejemplo, si cometes algún error al declarar una propiedad de la clase fuera de ella, es fácil perderla de vista, sobre todo al depurar cualquier error dentro de esa clase.

A partir de PHP 8.2, las propiedades dinámicas están depreciadas. Establecer un valor a una propiedad de clase no declarada emitirá un aviso de deprecació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, a partir de PHP 9.0, al establecerla se producirá un error en ErrorException.

Si tu código está lleno de propiedades dinámicas — y hay mucho código PHP que lo está — y si quieres detener estos avisos de deprecación después de actualizarte a PHP 8.2, puedes utilizar el nuevo atributo #[AllowDynamicProperties] de PHP 8.2 para permitir propiedades dinámicas 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;

De acuerdo con la RFC, las clases marcadas como #[AllowDynamicProperties], así como sus clases hijas, pueden seguir utilizando propiedades dinámicas sin necesidad de deprecarlas o eliminarlas.

También debes tener en cuenta que, en PHP 8.2, la única clase 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 lanzarán un aviso de deprecación.

Deprecación las Llamadas Parcialmente Soportadas

Otro cambio de PHP 8.2, aunque con un impacto más insignificante, es la deprecación de las llamadas parcialmente soportadas.

Estas llamadas se denominan parcialmente soportadas porque no puedes interactuar con ellas directamente a través de $callable(). Sólo puedes acceder a ellas con la función call_user_func($callable). La lista de estas llamadas no es larga:

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

A partir de PHP 8.2, cualquier intento de invocar estas llamadas — por ejemplo, a través de las funciones call_user_func() o array_map() — arrojará una advertencia de deprecación.

La RFC original ofrece un sólido razonamiento detrás de esta deprecación:

Aparte de los dos últimos casos, todas estas llamadas 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 comprobación de llamabilidad. En la práctica, esto suele ser válido también para los dos últimos casos, cuando se utiliza en la forma de [new Foo, "parent::method"].

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

RFC.
Según la RFC original, la función is_callable() y el tipo callable seguirán aceptando estas llamadas como excepciones. Pero sólo hasta que se elimine por completo el soporte para ellas a partir de PHP 9.0.

Para evitar confusiones, se ha ampliado el alcance de este aviso de deprecación con una nueva RFC — ahora incluye estas excepciones.

Es bueno ver que PHP avanza hacia la existencia de un tipo callable bien definido.

Deprecación de las Funciones #utf8_encode() y utf8_decode()

Las funciones incorporadas de PHP utf8_encode() y utf8_decode() convierten cadenas codificadas en ISO-8859-1 («Latin 1») a y desde UTF-8.

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

Además, normalmente verás 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 por lo demás legible.

PHP 8.2 deprecia las funciones #utf8_encode() y utf8_decode() . Si las invocas, verás estos avisos de deprecación:

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

La RFC sugiere utilizar en su lugar las extensiones soportadas por PHP como mbstring, iconv, y intl.

Deprecación de ${} Interpolación de String

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

  1. Incrustando directamente las variables — “$foo”
  2. Con llaves fuera de la variable — “{$foo}”
  3. Con llaves después del signo de dólar — “${foo}”
  4. Variables de la variable – “${expr}” — equivalente al uso de (string) ${expr}

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

A partir de ahora, debes evitar interpolar strings de esta manera:

"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 deprecaciones se actualizarán para lanzar una excepción de error.

Deprecación de las Funciones mbstring para las entidades Base64/QPrint/Uuencode/HTML

Las funciones mbstring (cadena multibyte) 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 siguen formando parte de estas funciones, principalmente por razones de legado. PHP también incluye implementaciones separadas de estas codificaciones.

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

Además, PHP siempre está mejorando sus funciones incorporadas, como en PHP 8.1 con las funciones de codificación y decodificación de HTML.

Así que, teniendo todo esto en cuenta, en PHP 8.2 está deprecado el uso de mbstring para estas codificaciones (las etiquetas no distinguen entre mayúsculas y minúsculas):

  • BASE64
  • UUENCODE
  • HTML-ENTITIES
  • html (alias de HTML-ENTIDADES)
  • Quoted-Printable
  • qprint (alias de Quoted-Printable)

A partir de PHP 8.2, el uso de mbstring para codificar/decodificar cualquiera de las anteriores emitirá un aviso de deprecación. PHP 9.0 eliminará por completo el soporte de mbstring para estas codificaciones.

Otros Cambios Menores en PHP 8.2

Por último, podemos hablar de los cambios menores de PHP 8.2, incluyendo sus características y funcionalidades eliminadas.

Eliminación del Soporte para libmysql de mysqli

A partir de ahora, PHP permite que los controladores mysqli y PDO_mysql construyan contra las bibliotecas mysqlnd y libmysql. Sin embargo, el controlador por defecto 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 y las pruebas unitarias de PHP.

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

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

La RFC también enumera algunas ventajas de libmysql, entre ellas:

  • Es posible la reconexión automática ( mysqlnd no soporta esta funcionalidad intencionadamente porque puede ser fácilmente explotada)
  • Modos de autenticación LDAP y SASL (mysqlnd podría añadir esta función también en breve)

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

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

Si quieres añadir alguna funcionalidad que sólo esté disponible con libmysql, tendrás que añadirla explícitamente a mysqlnd como petición de función. Además, no puedes añadir la reconexión automática.

Conversión de Casos Independiente de la Localización

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

La configuración del idioma durante la instalación de Linux establecerá el idioma apropiado de la interfaz de usuario para sus comandos incorporados. Sin embargo, también cambia de forma inesperada el funcionamiento del manejo de strings de la biblioteca C.

Por ejemplo, si seleccionaste el idioma «turco» o «kazajo» al instalar Linux, verás que al llamar a toupper('i') para obtener su equivalente en mayúsculas obtendrás la I mayúscula con puntos (U+0130, İ).

PHP 8.0 puso fin a esta anomalía estableciendo la configuración regional por defecto en «C», a menos que el usuario la cambie explícitamente a través de setlocale().

PHP 8.2 va incluso más allá al eliminar la sensibilidad de la configuración regional en las conversiones de mayúsculas y minúsculas. Esta RFC cambia principalmente strtolower(), strtoupper(), y las funciones relacionadas. Lee la RFC para obtener una lista de todas las funciones afectadas.

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

Mejora de la Extensión Aleatoria

PHP está planeando revisar su funcionalidad aleatoria.

Hasta ahora, la funcionalidad aleatoria de PHP depende en gran medida del estado 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. Añadir funciones de aleatorización entre la etapa de siembra inicial y el uso previsto rompería el código.

Mantener ese código puede ser aún más complicado cuando tu código utiliza paquetes externos.

Por tanto, la funcionalidad aleatoria actual de PHP no puede reproducir valores aleatorios de forma consistente. Incluso falla en las pruebas estadísticas empíricas de los 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 tanto, no se recomienda utilizar las funciones incorporadas de PHP — shuffle(), str_shuffle(), array_rand() — si necesitas números aleatorios criptográficamente seguros. En estos casos, tendrás que implementar una nueva función utilizando random_int() o funciones similares.

Sin embargo, se plantearon varios problemas con esta RFC una vez iniciada la votación. Este contratiempo obligó al equipo de PHP a anotar todas las cuestiones en una RFC separada, con una opción de votación creada para cada cuestión. Sólo decidirán si siguen adelante cuando lleguen a un consenso.

RFCs 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 añade esta nueva función a su extensión Curl. Llama a la función curl_easy_upkeep() en libcurl, la biblioteca C subyacente que utiliza la extensión Curl de PHP.
  2. Nueva función ini_parse_quantity: Las directivas INI de PHP aceptan tamaños de datos con un sufijo multiplicador. Por ejemplo, puedes escribir 25 Megabytes como 25M, o 42 Gigabytes como sólo 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 INI de PHP y devuelve su tamaño en bytes.
  3. Nueva función memory_reset_peak_usage: Esta función restablece el pico de uso de memoria devuelto por la función memory_get_peak_usage. Puede ser útil cuando ejecutas la misma acción varias veces y quieres registrar el uso máximo de memoria de cada ejecución.
  4. Soporte para el modificador de no captura (/n) en las funciones de preg_*: En regex, los metacaracteres () indican un grupo de captura. Esto significa que se devuelven todas las coincidencias de la expresión dentro del paréntesis. PHP 8.2 añade un modificador de no captura (/n) para detener este comportamiento.
  5. Haz que la familia iterator_*() acepte todos los iterables: Hasta ahora, la familia iterator_*() de PHP sólo acepta \Traversables (es decir, no admite arrays simples). Esto es innecesariamente limitante, y esta RFC lo soluciona.

Resumen

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

Estamos impacientes por comparar PHP 8.2 con varios frameworks de PHP y CMSs.

Asegúrate de marcar esta entrada del blog para consultarla en el futuro.

¿Qué características de PHP 8.2 son tus favoritas? ¿Qué depreciaciones son las que menos te gustan? Comparte tu opinión con nuestra comunidad en los comentarios

Salman Ravoof

Salman Ravoof es desarrollador web autodidacta, escritor, creador y un gran admirador del Software Libre y de Código Abierto (FOSS, Free and Open Source Software). Además de la tecnología, le apasionan la ciencia, la filosofía, la fotografía, las artes, los gatos y la comida. Obtén más información sobre él en su sitio web, y conecta con Salman en X.