2009-12-03 13 views
17

Ich lese Douglas Crockfords Javascript: The Good Parts, Ich habe gerade die regulären Ausdrücke Kapitel beendet. In diesem Kapitel nennt er \b der JavaScript, um positive Vorschau (?=) und negative Vorschau (?!)„kein guter Teil“JavaScript: Die guten Teile; Warum ist Lookahead nicht gut?

Er erklärt, der Grund für \b nicht gut zu sein (es verwendet \w für Wortgrenze zu finden, und \w nicht für jeden Sprache, die Unicode-Zeichen verwendet), und das sieht für mich einen sehr guten Grund aus.

Leider ist der Grund für positive und negative Lookahead nicht gut, und ich kann nicht mit einem kommen. Mastering Regular Expressions zeigte mir die Macht, die mit Lookahead kommt (und natürlich die damit verbundenen Probleme), aber ich kann mir nichts vorstellen, was es als "keinen guten Teil" qualifizieren würde.

Kann jemand erklären, warum JavaScript (positiv | negativ) Lookahead oder (positiv | negativ) Lookahead im Allgemeinen als "nicht gut" betrachtet werden sollte?

Es scheint, ich bin nicht der einzige mit dieser Frage: one und two.

+1

In dem Moment, in dem ich diesen Satz gelesen habe, habe ich ihn gegoogelt und mir das einfallen lassen. Sehr seltsam - alles andere, was er sagt, macht Sinn, und er erklärt fast immer seine Gründe dafür, Dinge als "schlecht" zu bezeichnen. – Skilldrick

+1

Ich stimme @Skilldrick zu. Crockford war wirklich gut darin, seine Argumentation für fast jeden Punkt zu erklären, den er in diesem Buch macht, aber in diesem Fall erklärt er überhaupt nichts. Ich habe auch gegoogelt, nachdem ich keine Erklärung gefunden hatte und bin hier gelandet. Es scheint mir so, als ob positive/negative Look-a-eads großartig sind, solange du verstehst, wie sie funktionieren und welche negativen Auswirkungen sie auf die Performance haben könnten, wenn sie unangemessen verwendet werden. – Chev

Antwort

10

Vielleicht liegt es am Internet Explorer perpetually buggy implementation of lookaheads. Für alle Autoren, die ein Buch über JavaScript erstellen, gibt es möglicherweise keine Funktion, die nicht in IE funktioniert.

+9

Ich weiß nicht, was Herr Crockford dachte, als er dies schrieb, aber das scheint der beste Grund, vorsichtig mit Lookahead in Javascript zu sein. Es ist ein bisschen unfair, die Sprache für fehlerhafte Implementierungen verantwortlich zu machen. –

+6

Remember: JavaScript kann außerhalb des Webs verwendet werden, wie node.js beweist! –

+1

Sicherlich! Denken Sie jedoch daran, dass Javascript: die guten Teile wurden geschrieben, bevor node.js kam, so dass dies immer noch als die beste Antwort qualifiziert. –

2

Sie sind zu schwer für ihn?

Oder: Lookaheads und Lookbehinds (letztere werden in JavaScript nicht unterstützt) erhöhen die Regex-Zeiten erheblich. Aber in JavaScript werden normalerweise keine großen Datenmengen regexportiert. Sie sind großartig. benutze sie, wenn sie nützlich sind.

+1

zu schwer scheint unwahrscheinlich ... Leistung könnte ein Grund sein, aber das ist eher ein Interpreter-Problem, das gelöst werden könnte als ein Sprachspezifikationsproblem. –

+3

Ich war nicht wirklich ernst mit dem "zu hart" Bit. Aber Dolmetscherprobleme scheinen gute Gründe zu sein, um zu sagen, dass ein Sprachmerkmal vermieden werden sollte. Aber auch hier würde ich Crockford nicht zustimmen, dass es irgendein Problem gibt, das Lookaheads wert ist, vermieden zu werden. Lookarounds sind fantastisch. –

+4

Crockford ist ein kluger Kerl, und ich finde, er besser wissen würde, als jemand, warum er geschlossen Lookaheads schlecht sind, so dass ich warf ihm eine E-Mail.Wenn er antwortet, werde ich es hier posten (wenn er das nicht selbst tut). –

3

Der einzige Grund, warum ich denken kann, ist, dass sie nur von etwa der Hälfte der gängigen regulären Ausdrucksmaschinen unterstützt werden. Wenn Sie sich jedoch auf die universell unterstützte Syntax beschränken, gibt es viele Dinge, die Sie einfach nicht tun können.

Durch die Art und Weise (positive | negativ) (Look-Ahead | Lookbehind) bezeichnet werden manchmal kollektiv als „Lookarounds“, wie in dieser Seite, die die Unterstützung von Funktionen unter verschiedenen Implementierungen vergleicht:

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

+3

Ich habe auch in diese Richtung gedacht, aber Mangel an Unterstützung im Allgemeinen qualifiziert es nicht wirklich als einen schlechten Teil einer spezifischen Sprache, die es tatsächlich unterstützt. –