El resumen semanal de PHP Internals reunió diez temas. Entre ellos estuvieron el RFC IntlRelativeDateTimeFormatter, array_str_contains, el manejo de errores de expresiones regulares, el futuro de PEAR y los próximos hitos de PHP.

Weilin Du abrió el martes la votación de IntlRelativeDateTimeFormatter. El RFC trata el formato de fechas y horas relativas de ICU para la extensión intl, con salidas como «3 days ago» y «next Sunday». Unos diez minutos después, Tim Düsterhus votó en contra. La votación mostraba cuatro votos a favor y uno en contra cuando Du la cerró antes de que transcurriera una hora.

Düsterhus explicó que el RFC había cambiado después de su revisión. No recibió un mensaje que confirmara que las modificaciones ya estaban aplicadas y su intención de votar había caducado. También cuestionó el uso de constantes enteras sin tipo cuando los enums podían definir esos valores con más precisión. Du describió el episodio como un malentendido, lo consideró un cambio importante y retiró la votación. El miércoles, Düsterhus propuso tres enums para estilo, capitalización y unidad, sin namespace. Su ejemplo transforma `IntlRelativeDateTimeFormatter::UNIT_DAY` en `IntlRelativeDateTimeFormatterUnit::Day`. El diseño permitiría autocompletado en el IDE, casos documentables y comprobaciones de entrada del motor. `RoundingMode` sirvió como precedente.

El benchmark incluido en la propuesta de array_str_contains debilitó su argumento. Yuya Hamada ejecutó la prueba distribuida con la pull request. Cuando el elemento coincidía al principio del array, la función nativa en C tardaba 578 milisegundos, frente a 14 milisegundos de un bucle foreach. La función nativa también perdía en las coincidencias del medio y del final. Solo igualaba al bucle cuando no había coincidencias. Sepehr Mahmoudi cuestionó la ejecución porque los archivos no compilaban en su entorno. El domingo eliminó las pruebas de benchmark de la propuesta.

Kamil Tekiela recordó el criterio para añadir funciones a la biblioteca estándar. La conducta debe ser imposible o muy difícil de reproducir en userland, o suficientemente habitual como para justificar una API propia. mickmackusa consideró insuficiente una implementación C más rápida para añadir una función a la familia array. Larry Garfield señaló que nadie estaba revisando los benchmarks porque la propuesta no tenía apoyo activo. También recordó que las propuestas de colaboradores experimentados pueden ser rechazadas. El miércoles por la noche, el RFC seguía en el wiki y no tenía una votación programada.

El RFC PREG_THROW_ON_ERROR mantiene abierta una decisión de diseño. Una excepción lanzada por un callback de `preg_replace_callback` podría envolverse en `PregException` o propagarse directamente. Tim Düsterhus, autor de la política sobre throwables, defiende el envoltorio. Otros tres participantes se inclinaron esta semana por la propagación. Casper Langemeijer dijo que no conocía ningún callback de PHP que el lenguaje envolviera, incluido el autoloading. Sascha Ploss citó JavaScript, Python, Java, C#, Rust y Ruby, donde las excepciones del callback se propagan.

Osama Aldemeery, autor del RFC, aclaró el comportamiento del código C. Una excepción del callback establece actualmente `preg_last_error` en `PREG_INTERNAL_ERROR`, porque la ruta de interrupción pasa el número de coincidencias a una función de errores sin un caso correspondiente. El motor de expresiones regulares puede haber procesado correctamente la coincidencia, mientras la ruta de interrupción deja un error genérico. La garantía de que el mensaje de la excepción coincide con `preg_last_error_msg` solo se aplica a una llamada con el flag activado. Düsterhus propuso después que ese flag no modificara `preg_last_error`, siguiendo el comportamiento de `JSON_THROW_ON_ERROR`. En ese caso bastaría una `PregException`, o una combinación de `PregError` y `PregException`. Aldemeery dejó la decisión política en manos de Düsterhus, que el jueves todavía no la había tomado.

La recuperación de los datos de errores de PEAR cambió el RFC sobre el final de su respaldo. Nick S. sustituyó la sección sobre el alcance futuro por una descripción de la situación actual y un calendario explícito, después de coordinarse con Derick Rethans. También eliminó la afirmación de que los intentos de contactar con los mantenedores de PEAR no habían tenido respuesta. Los cambios fueron importantes, así que el debate seguirá abierto al menos hasta el 27 de septiembre.

Chuck recuperó las páginas de errores que faltaban. El archivo podrá quedar completo. Juliette Reinders Folmer agradeció a ambos colaboradores. Jakub Zelenka preguntó si php-src debía desacoplar PEAR antes de que el sitio pasara a funcionar como contenido estático. Cree que el build de Windows todavía usa el instalador y planea retomar esa pull request en octubre o noviembre. Nick S., tras comprobarlo con Derick Rethans, indicó que el cambio del sitio podía hacerse primero si `go-pear.phar` y las demás URL continuaban sirviéndose desde el mismo dominio. La votación no puede terminar antes de mediados de octubre. Nick no espera una integración antes de noviembre. Otra pull request de Daniel Scherzer incorpora el phar del instalador de PEAR al repositorio durante la preparación de una release y apunta a 8.2.

El corte de la rama PHP 8.6 está previsto para el 22 de septiembre, junto con el empaquetado de 8.6.0 RC1. Será el congelamiento estricto de funcionalidades. Después, master pasará a ser 8.7. Beta 3 se publicó el 10 de septiembre y RC1 se esperaba para el 24 de septiembre. También había release candidates de 8.5.11 y 8.4.26.

Matthieu Napoli obtuvo RFC karma para `--enable-cli-fpm`. Esta opción de compilación enlaza FPM con el binario de PHP. El comando `php --fpm` ejecuta FPM. Con Bref en Lambda, un segundo binario de 24 megabytes aumenta actualmente el tiempo de arranque en frío. Marc Henderkes quiere que la opción sea el comportamiento predeterminado.

Una propuesta de agosto permitiría comentarios y comas finales en JSON. Tim sugirió un único flag, `JSON_ALLOW_JSONC`, basado en el estándar JSONC existente. Vilius Buividavičius propuso `MyClass::properties::name` como forma constante de referirse a los nombres de propiedades. Doctrine podría así evitar cadenas codificadas manualmente. Nick S. señaló un debate anterior sobre la misma idea.

Alwyn Bester publicó `php-grammar`, una gramática EBNF de PHP 8.5 basada en las fuentes y comprobada frente al parser. Pidió revisiones en la lista y reactivó un debate de hace 15 años sobre una EBNF oficial para PHP. David Maye Kitenge preguntó por la propiedad de `zend_string` al trasladar una extensión desde código generado por Zephir a C escrito manualmente. Alexandru Pătrănescu explicó que `static` describe la variable de C y no cambia el refcount de la cadena. Zend y OPcache son propietarios de las cadenas internadas. Las extensiones no deben liberarlas directamente. Las cadenas permanentes deben internarse en MINIT. Una cadena internada durante una petición no debe considerarse válida después de esa petición.

El miércoles por la noche, el wiki no mostraba ningún RFC en votación por quinta semana consecutiva.