tag - JavaScript: Las partes buenas; ¿Por qué el lookahead no es bueno?
title html javascript (3)
¿Son demasiado duros para él?
O: lookaheads y lookbehinds (estos últimos no son compatibles con JavaScript) aumentan considerablemente los tiempos de expresión regular. Pero uno no está típicamente regexing a través de enormes cantidades de datos en JavaScript. Así que son geniales; Úsalos cuando sean útiles.
Estoy leyendo Douglas Crockfords Javascript: The Good Parts , acabo de terminar el capítulo de expresiones regulares. En este capítulo, él llama /b JavaScript, lookahead positivo (?=) Y lookahead negativo (?!) "No es una buena parte"
Explica la razón por la cual /b no es bueno (usa /w para la búsqueda de límites de palabras y /w falla para cualquier idioma que usa caracteres Unicode), y me parece una muy buena razón.
Desafortunadamente, la razón por la cual el aspecto positivo y negativo no es bueno se omite, y no puedo encontrar uno. El dominio de las expresiones regulares me mostró el poder que viene con lookahead (y, por supuesto, explica los problemas que conlleva), pero realmente no puedo pensar en nada que lo califique como "no una buena parte".
¿Alguien puede explicar por qué JavaScript (lookahead positivo / negativo) o lookahead (positivo / negativo) en general debe considerarse "no bueno"?
La única razón por la que puedo pensar es que solo son compatibles con la mitad de los populares motores de expresiones regulares, aunque si te limitas a la sintaxis con soporte universal, hay muchas cosas que simplemente no puedes hacer.
Por cierto, (positivo | negativo) (lookahead | lookbehind) a veces se denomina colectivamente "lookaround", como en esta página que compara el soporte de características entre varias implementaciones:
Tal vez sea debido a la implementación perpetuamente con errores de Internet Explorer de lookaheads . Para cualquier persona que cree un libro sobre JavaScript, cualquier característica que no funcione en IE podría no existir.