Estaba leyendo la página web de Douglas Crockford, JavaScript: The World's Most Misunderstood Programming Language, y no pude evitar observar que, en Design Errors, menciona "la notación para expresiones regulares literales". ¿De qué está hablando él exactamente? ¿Qué hay de malo con la notación de JavaScript para expresiones regulares, y por qué?¿Qué pasa con la notación de expresiones regulares de JavaScript?
Podría tener que ver con el hecho de que le obliga a escapar de los caracteres /, tal vez quería un carácter más único para usar como notación.
/test// no es válido, mientras que /test\// es una expresión regular válida.
Mientras que en algunos idiomas en realidad se puede especificar el carácter denotion en una cadena, por ejemplo:
$regex = '#test/#';
Dónde # símbolos hacen la denotion.
Realmente no tiene muy claro lo que quiere decir que la inserción del punto y coma es un error. Quizás él quiere decir punto y coma como delimitadores de enunciados. Si ese es el caso, no estoy de acuerdo. Sin punto y coma, los ofuscadores/minificadores del código no se ejecutan en tu código.
Su queja sobre la inserción de punto y coma es que los puntos y comas son "opcionales" y por lo tanto se insertan. Pero la pregunta es sobre la porción en negrita en los literales de expresiones regulares no sobre la inserción de punto y coma. – eyelidlessness
Gracias por su respuesta, pero estaba preguntando específicamente sobre la parte en negrita en la pregunta. – alex
Estaba confundido :) Parece una farsa para mí. El autor simplemente está haciendo quejas sin entrar en detalles en cuanto a por qué cree que JavaScript está mal diseñado. – jmort253
Me imagino que la notación literal de expresiones regulares es un obstáculo para la evolución del motor de expresiones regulares desacoplado de la especificación del lenguaje.
Si todas las expresiones regulares eran cadenas, siempre fueron válidas en el nivel de idioma, y el motor de expresiones regulares podría interpretarlas más libremente.
Pero eso es solo una suposición. No tengo idea de qué quiso decir Crockford con su declaración.
Personalmente, me parecen bastante útiles los literales de expresiones regulares. Son mucho menos detallados que la alternativa new RegExp(pattern, flags) con su necesidad de cumplir tanto con las reglas de escape de cadena como que escapan las expresiones regulares ("Path\\\\with\\\\backslashes", ¿alguien?). No puedo ver el gran beneficio para esta notación, que no sea para tratar con expresiones regulares dinámicas.
Muy cierto, eso es probablemente. Pero, ¿qué idiomas, además de PHP, te permiten especificar el personaje? Me cuesta pensar en alguno, pero podría ser porque casi nunca uso expresiones regulares. –
Sí. La queja de Crockford era sobre "sobrecargar" al personaje de slash, pero creo que su principal preocupación era sobre la sobrecarga en JS en general (¡creo!). Por ejemplo, si comenta bloques de código con '/*...*/', puede ver qué pasaría si intentara hacer un comentario '/0x[0-9a-f]*/.test(strMyString); 'con eso. Hubo un montón de veces que tuve que usar el método RegExp() para crear expresiones regulares porque los literales eran propensos a errores. – Andrew
@Andrew realmente? Veo cómo es posible, pero nunca me he encontrado con eso. –