ECMAScript 3 tiene algunas fallas importantes en el diseño de expresiones regulares y, si nada cambia, el grupo ES4 propagará algunos de los errores a ECMAScript 4 (también conocido como JavaScript 2).
Recientemente, el veterano gurú de expresiones regulares de JavaScript, David "liorean" Andersson, escribió un par de publicaciones sobre mis mayores quejas con el sabor de expresiones regulares de ECMAScript 3, a saber, la forma en que se manejan las referencias inversas para grupos de captura no participantes y dentro de subpatrones cuantificados (ver Expresiones regulares de ECMAScript 3 :una especificación que no tiene sentido y una prueba rápida de JS para cualquiera que crea saber expresiones regulares). Evitaré repetir los puntos aquí, ya que creo que David ya articuló bien los problemas. Para que conste, había planeado enviar estos problemas como errores de ECMAScript 4, pero ya tengo varios tickets de expresiones regulares de ES4 abiertos y estaba esperando ver su resultado antes de enviar más.
Otro problema históricamente problemático ha sido el hecho de que, según ES3, los literales de expresiones regulares hacen que solo se cree un objeto en tiempo de ejecución para un script o una función. Este problema se presenta con más frecuencia como expresiones regulares que usan el /g modificador que no tiene su lastIndex restablecimiento de propiedad en algunos casos donde la mayoría de los desarrolladores lo esperarían. Afortunadamente, esto ya está planeado para solucionarse en ES4. El hecho de que haya sido el tercer informe de error de Firefox más duplicado sin duda tuvo algo que ver con esta decisión.
Pero volviendo a mi diatriba original, aunque los problemas de manejo de referencias inversas pueden ser menos visibles para algunos desarrolladores que tener lastIndex de sus objetos regex propiedades aparentemente fuera de control, no son más sensibles o están en línea con las expectativas del desarrollador. Además, el manejo de ES3 para estos problemas es incompatible con otras bibliotecas de expresiones regulares modernas, y mucho menos útil que el manejo alternativo (consulte, por ejemplo, Mimicking Conditionals y Capturing Multiple, Optional HTML Attribute Values para ver un par de ejemplos de cómo funciona el manejo convencional de estilo Perl). podría tener un buen uso).
Como una diatriba relacionada, en mi humilde opinión, las propuestas de extensión de expresiones regulares ECMAScript 4 pierden algunas oportunidades para adiciones de funciones clave. Esto es lo que agregan las expresiones regulares de ES4, junto con algunos cambios relacionados con la compatibilidad y la capacidad de que los literales de expresiones regulares abarquen varias líneas:
- Operaciones de conjuntos de clases de caracteres:intersección y resta, con sintaxis inspirada en java.util.regex.
(?#…)patrones de comentarios.- Captura con nombre, aunque parece que esto no se pensó del todo. Sin embargo, parece que el grupo TG1 podría estar dispuesto a cambiar la sintaxis propuesta en el borrador de la especificación a la sintaxis .NET/Perl más común, lo que sería una mejora.
- El
/ymodificador (adhesivo):similar al uso de\Gen otras bibliotecas . - El
/xmodificador (extendido) — para espacios libres y comentarios. - Propiedades de caracteres Unicode, pero no hay soporte para secuencias de comandos o bloques Unicode, y no hay
\Xmetasecuencia para que coincida con un solo grafema, lo que significa que tendrás que usar\P{M}\p{M}*. - Compatibilidad con códigos de caracteres hexadecimales fuera del plano multilingüe básico de Unicode:a través de
\x{n…}y\u{n…}, que son equivalentes.
Para obtener una descripción de estas características, consulte la wiki de ES4, pero tenga en cuenta que muchos de los detalles más finos de cómo funcionarán no se mencionan o se discuten en otros lugares, como en la lista de correo [email protected] ( archivo externo aquí) o dentro de la base de datos de problemas de ECMAScript 4.
Aparte de algunos detalles de su implementación actualmente propuesta (que en su mayor parte ya mencioné en otro lugar), creo que estas adiciones son geniales. Sin embargo, para ser honesto, si pudiera cambiar todas las extensiones de expresiones regulares de ES4 por grupos atómicos y mirar hacia atrás, lo haría. Y si bien es comprensible que diferentes personas tengan diferentes prioridades, la falta de grupos atómicos en particular es una omisión importante si se tiene en cuenta su poder de mejora del rendimiento potencialmente drástico combinado con su carga de implementación mínima. Las características adicionales que se encuentran en Perl u otras bibliotecas de expresiones regulares derivadas de Perl que podrían ser bastante útiles incluyen cuantificadores posesivos, verbos de control de retroceso, modificadores de modo y tramos modificados por modo, condicionales, \A y \z aserciones, llamadas, referencias inversas relativas, recursividad, subpatrones como subrutinas, restablecimiento del punto de coincidencia (a través de \K ), números de subpatrones duplicados (?|…) , definiciones de subpatrones (?(DEFINE)…) , coincidencia parcial, coincidencia inversa, etc.
Dado que el grupo ECMA TG1 ha declarado que ya no aceptará las principales propuestas de especificaciones, espero que las adiciones se limiten a las ya propuestas. Sin embargo, tengo la esperanza de que la situación mejore, al menos refinando algunas de las características existentes de ES3 y las propuestas de ES4. Dado que me encantan tanto JavaScript como las expresiones regulares, me encantaría verlos juntos de una manera que compita con las mejores bibliotecas de expresiones regulares. Tal vez ECMAScript podría incluso introducir una pequeña innovación en el espacio.