2009-12-03 9 views
17

Sto leggendo Douglas Crockfords Javascript: The Good Parts, ho appena finito il capitolo delle espressioni regolari. In questo capitolo si chiama, guarda avanti positiva (?=) e lookahead negativo (?!)"non è una buona parte" di \b JavaScriptJavaScript: Le parti buone; perché guardare avanti non va bene?

Egli spiega il motivo per \b essere non va bene (usa \w per Finding limite di parola, e \w non riesce per qualsiasi linguaggio che usa caratteri unicode), e mi sembra un'ottima ragione.

Sfortunatamente, il motivo per cui il lookahead positivo e negativo non è buono viene escluso e non riesco a inventarne uno. Mastering Regular Expressions mi ha mostrato il potere che viene fornito con lookahead (e ovviamente spiega i problemi che comporta), ma non posso davvero pensare a qualcosa che lo qualificherebbe come "non una buona parte".

Qualcuno può spiegare perché JavaScript (positivo | negativo) lookahead o (positivo | negativo) guarda avanti in generale dovrebbe essere considerato "non buono"?

Sembra che non sia l'unico con questa domanda: one e two.

+1

Nel momento in cui ho letto quella frase l'ho cercato su google, e ne sono venuto fuori. Molto strano - tutto il resto dice che ha perfettamente senso, e quasi sempre spiega le sue ragioni per dire che le cose sono "cattive". – Skilldrick

+1

Sono d'accordo con @Skilldrick. Crockford è stato davvero bravo a spiegare il suo ragionamento per quasi ogni punto che fa in questo libro, ma in questo caso non spiega assolutamente nulla. Anch'io ho cercato su Google dopo aver trovato alcuna spiegazione e finito qui. A me sembra che i lookahead positivi/negativi siano fantastici finché capisci come funzionano e l'impatto potenzialmente negativo che potrebbero avere sulle prestazioni se usato in modo inappropriato. – Chev

risposta

10

Forse è a causa di Internet Explorer perpetually buggy implementation of lookaheads. Per chiunque sia autore di un libro su JavaScript, qualsiasi funzione che non funziona in IE potrebbe anche non esistere.

+9

Non so cosa stava pensando il signor Crockford quando ha scritto questo, ma questo sembra il miglior motivo per stare attenti con lookahead in javascript. Tuttavia, è un po 'ingiusto dare la colpa alla lingua per le implementazioni bacate. –

+6

Ricorda: JavaScript può essere usato al di fuori del web, come dimostra node.js! –

+1

Certamente! Ricorda però che Javascript: le parti buone sono state scritte prima che node.js arrivasse, quindi questo si qualifica ancora come la migliore risposta. –

2

Sono troppo difficili per lui?

Oppure: lookaheads e lookbehinds (questi ultimi non sono supportati in JavaScript) aumentano notevolmente i tempi di regex. Ma in genere non si esegue la regexing attraverso enormi quantità di dati in JavaScript. Quindi sono fantastici; usali quando sono utili

+1

troppo difficile sembra improbabile ... le prestazioni potrebbero essere un motivo, ma si tratta più di un problema di interprete che potrebbe essere risolto rispetto a un problema di specifica del linguaggio. –

+3

Non ero davvero serio con il bit "troppo difficile". Ma i problemi dell'interprete sembrano buoni motivi per dire che un linguaggio dovrebbe essere evitato. Ma, ancora una volta, non sarei d'accordo con Crockford sul fatto che ci sia un qualsiasi tipo di problema che possa far sì che i punti di interesse siano degni di essere evitati. I lookaround sono fantastici. –

+4

Crockford è un ragazzo intelligente, e immagino che saprebbe meglio di chiunque altro perché ha concluso che i problemi di amministrazione sono cattivi, quindi gli ho mandato una mail.Se risponde, lo posterò qui (se non lo fa lui stesso). –

3

L'unica ragione per cui posso pensare è che sono supportati solo da circa la metà dei popolari motori di espressioni regolari, sebbene se ci si limita a una sintassi supportata universalmente ci sono molte cose che non si possono fare.

Tra l'altro (positivo | negativo) (lookahead | lookbehind) è a volte indicato collettivamente come "Lookaround", come in questa pagina che mette a confronto il supporto di funzionalità tra le diverse implementazioni:

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

+3

Anche io stavo pensando in questa direzione, ma la mancanza di supporto in generale non lo qualifica come una brutta parte di un linguaggio specifico che effettivamente lo supporta. –

Problemi correlati