2015-07-26 11 views
5

Ich bin neugierig auf die Best Practices für die Verwendung einer anderen Regex-Engine anstelle der Standard-Perl One und warum die Module, die ich gesehen habe, sind Pragmas und keine traditionellere OO/prozedurale Schnittstelle. Ich habe mich gefragt, warum das so ist.Warum eine andere Regex-Engine (z. B. PCRE) als Pragma implementieren?

Ich habe eine Handvoll Module zum Ersetzen der Perl-Regex-Engine mit PCRE (re :: engine :: PCRE), TRE (re :: engine :: TRE) oder RE2 (re :: engine :: RE2) in einem gegebenen lexikalischen Kontext. Ich kann keine objektorientierten Module zum Erstellen/Kompilieren regulärer Ausdrücke finden, die ein anderes Backend verwenden. Ich bin neugierig, warum jemand diese Funktionalität als Pragma und nicht als ein typischeres Modul implementieren würde. Es scheint so, als ob das Ersetzen der Perl-Regex-Engine viel schwieriger wäre (abhängig von der Komplexität der API), als ein XS-Skript zu erstellen, das die API bereitstellt, die PCRE, TRE und RE2 bereits bereitstellen.

+4

Was sagten die Autoren dieser Module, als Sie sie fragten? –

+0

Es liegt daran, dass es in Perl natürlicher ist, 's/re/repl /' zum Beispiel zu verwenden, als irgendeine Modulmethode aufzurufen. Außerdem müssten Sie 'q/re /' anstelle von Regex-Literalen verwenden. –

+0

@CalleDybedahl Ich habe sie nicht gefragt. Ich dachte, es wäre unhöflich, eine solche grundlegende Frage direkt an die Paketbetreuer zu richten, anstatt an ein allgemeines Forum. –

Antwort

5

Ich bin neugierig auf ... warum die Module, die ich gesehen habe, Pragmas sind und keine traditionellere OO/prozedurale Schnittstelle.

Wahrscheinlich, weil der Perl regex API, da 5.9.5 in perldoc perlreapi und verfügbar dokumentiert, können Sie die Vorteile von Perl-Parser übernehmen, die Sie viele coole Features mit wenig Code gibt.

Wenn Sie die API verwenden, Sie:

  • haben keine eigene Version von split und die Substitution Operator zu implementieren s///
  • müssen nicht Ihren eigenen Code schreiben regex Modifikatoren zu analysieren (msixpn werden als Flags an die Callback-Funktionen Ihrer Implementierung übergeben)
  • kann Optimierungen nutzen wie konstante Regexe, die nur einmal kompiliert werden (zur Kompilierzeit) und Regexes, die interpolierte Variablen enthalten, die nur kompiliert werden, wenn sich die Variablen ändern
  • können qr in Ihren Programmen verwenden, um reguläre Ausdrücke zu zitieren und sie leicht in andere Regexes zu interpolieren.
  • kann einfach nummerierte und benannte Capture-Variablen, z. $1, $+{foo}
  • zwingen Sie die Benutzer Ihrer Engine nicht dazu, den gesamten Code neu zu schreiben, um Ihre API zu verwenden. sie können einfach ein Pragma

hinzufügen Es gibt wahrscheinlich mehr, dass ich verpasst habe. Der Punkt ist, dass Sie mit der API viel freien Code und kostenlose Funktionalität erhalten. Wenn Sie beispielsweise die Implementierung von re::engine::PCRE betrachten, ist sie tatsächlich ziemlich kurz (< 400 Zeilen XS-Code).

Alternativen

Wenn Sie nur für einen einfacheren Weg suchen, um Ihren eigenen Regex-Engine zu implementieren Besuchen re::engine::Plugin, die Sie in Perl anstelle von C/XS schreiben Sie Ihre Implementierung ermöglicht. Beachten Sie, dass es eine lange Liste von caveats, einschließlich keine Unterstützung für split und s/// gibt.

Alternativ zur Implementierung einer vollständig benutzerdefinierten Engine können Sie die integrierte Engine mithilfe von überladenen Konstanten erweitern, wie in perldoc perlre beschrieben. Dies funktioniert nur in konstanten Regexes; Sie müssen Variablen explizit konvertieren, bevor Sie sie in eine Regex interpolieren.