2009-12-03 8 views
17

Estoy leyendo Douglas Crockfords Javascript: The Good Parts, acabo de terminar el capítulo de expresiones regulares. En este capítulo se llama, de búsqueda positiva hacia (?=) y búsqueda negativa hacia delante (?!)"no es una buena parte" de \b JavaScriptJavaScript: Las buenas partes; ¿Por qué no es bueno mirar hacia adelante?

Explica la razón de \b ser no es bueno (que utiliza \w para la búsqueda de límite de palabra, y \w falla por cualquier lenguaje que usa caracteres Unicode), y eso parece una muy buena razón para mí.

Desafortunadamente, la razón por la que la anticipación positiva y negativa no es buena queda fuera, y no puedo encontrar una. Mastering Regular Expressions me mostró el poder que viene con la búsqueda anticipada (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 (positive | negative) lookahead o (positive | negative) lookahead en general deberían considerarse "no buenos"?

Parece que no soy el único con esta pregunta: one y two.

+1

En el momento en que leí esa frase la busqué en Google y se me ocurrió esto. Muy extraño, todo lo demás que dice tiene mucho sentido, y casi siempre explica sus razones para decir que las cosas son "malas". – Skilldrick

+1

Estoy de acuerdo con @Skilldrick. Crockford ha sido muy bueno en explicar su razonamiento para casi cada punto que hace en este libro, pero en este caso no explica nada en absoluto. Yo también busqué en Google después de no encontrar ninguna explicación y terminé aquí. Me parece que los aspectos positivos/negativos son impresionantes siempre que entiendas cómo funcionan y el impacto potencialmente negativo que podrían tener en el rendimiento si se usan de forma inapropiada. – Chev

Respuesta

10

Tal vez es debido a perpetually buggy implementation of lookaheads de Internet Explorer. Para cualquier persona que cree un libro sobre JavaScript, cualquier característica que no funcione en IE podría no existir.

+9

No sé lo que el Sr. Crockford estaba pensando cuando escribió esto, pero esta parece ser la mejor razón para tener cuidado con la búsqueda en javascript. Sin embargo, se siente un poco injusto culpar al lenguaje por las implementaciones defectuosas. –

+6

Recuerde: JavaScript se puede usar fuera de la web, como demuestra node.js! –

+1

¡Ciertamente! Sin embargo, recuerde que Javascript: las partes buenas se escribieron antes de que llegara node.js, por lo que esta sigue calificando como la mejor respuesta. –

2

¿Son demasiado difíciles para él?

O: lookaheads y lookbehinds (estos últimos no son compatibles con JavaScript) aumentan considerablemente las expresiones regulares. Pero uno no es típicamente regexing a través de grandes cantidades de datos en JavaScript. Entonces son geniales; Úselos cuando sean útiles.

+1

demasiado difícil parece poco probable ... el rendimiento puede ser una razón, pero eso es más un problema de interpretación que un problema de especificación de idioma. –

+3

No estaba hablando en serio con el tema "demasiado difícil". Pero los problemas de los intérpretes parecen ser buenas razones para decir que se debe evitar una característica del lenguaje. Pero, una vez más, no estoy de acuerdo con Crockford en que haya algún tipo de problema que haga que valga la pena evitar las miradas. Las miradas son fantásticas. –

+4

Crockford es un tipo inteligente, y creo que sabría mejor que nadie por qué concluyó que las miradas son malas, así que le disparé un correo electrónico.Si responde, lo publicaré aquí (si él mismo no lo hace). –

3

La única razón que se me ocurre es que solo son compatibles con la mitad de los populares motores de expresiones regulares, aunque si te limitas a la sintaxis universalmente admitida hay muchas cosas que simplemente no puedes hacer.

Por cierto (positivo | negativa) (búsqueda hacia delante | búsqueda hacia atrás) a veces se denominan colectivamente como "lookaround", como en esta página que compara el respaldo de los servicios entre los diferentes implementaciones:

http://www.regular-expressions.info/refflavors.html

+3

Estaba pensando en esa dirección también, pero la falta de apoyo en general no lo califica como una parte mala de un lenguaje específico que en realidad lo respalda. –

Cuestiones relacionadas