Защо да внедрявате различна машина за регулярни изрази (напр. PCRE) като прагма?

Любопитен съм за най-добрите практики за използване на различен механизъм за регулярни изрази вместо стандартния Perl и защо модулите, които съм виждал, са прагми, а не по-традиционен OO/процедурен интерфейс. Чудех се защо е така.

Виждал съм шепа модули за замяна на Perl regex двигателя с PCRE (re::engine::PCRE), TRE (re::engine::TRE) или RE2 (re::engine::RE2) в даден лексикален контекст. Не мога да намеря никакви обектно-ориентирани модули за създаване/компилиране на регулярни изрази, които използват различен заден край. Любопитен съм защо някой би избрал да внедри тази функционалност като прагма, а не като по-типичен модул. Изглежда, че замяната на perl regex engine ще бъде много по-трудна (в зависимост от сложността на API, който излага), отколкото създаването на XS скрипт, който излага API, който PCRE, TRE и RE2 вече предоставят.


regex re2 perl pcre
person Gregory Nisbet    schedule 26.07.2015    source източник
comment
Какво казаха авторите на тези модули, когато ги попитахте?   -  person Calle Dybedahl    schedule 26.07.2015
comment
Това е така, защото в Perl е по-естествено да се използва s/re/repl/ например, отколкото да се извиква някакъв модулен метод. също така ще трябва да използвате q/re/ вместо регулярни изразни литерали.   -  person Lucas Trzesniewski    schedule 26.07.2015
comment
@CalleDybedahl Не съм ги питал. Мислех, че би било грубо да задавам такъв основен въпрос директно на поддържащите пакети, а не на по-общ форум.   -  person Gregory Nisbet    schedule 27.07.2015
comment
MarpaX::Languages::M4 е пример за OO пакет, който е използвайки друга машина за regexp   -  person Jean-Damien Durand    schedule 29.07.2015

Отговори (1)


arrow_upward
5
arrow_downward

Любопитен съм... защо модулите, които съм виждал, са прагми, а не по-традиционен OO/процедурен интерфейс.

Вероятно защото API на Perl regex, документиран в perldoc perlreapi и достъпен от 5.9.5, ви позволява да вземете предимство на парсера на Perl, който ви дава много страхотни функции с малко код.

Ако използвате API, вие:

  • не е нужно да прилагате своя собствена версия на split и оператора за заместване s///
  • не е нужно да пишете свой собствен код, за да анализирате модификаторите на регулярен израз (msixpn се предават като флагове към функциите за обратно извикване на вашата реализация)
  • може да се възползва от оптимизации като постоянни регулярни изрази, които се компилират само веднъж (по време на компилиране) и регулярни изрази, съдържащи интерполирани променливи, които се компилират само когато променливите се променят
  • може да използва qr във вашите програми, за да цитира регулярни изрази и лесно да ги интерполира в други регулярни изрази
  • може лесно да задава номерирани и именувани променливи за улавяне, напр. $1, $+{foo}
  • не принуждавайте потребителите на вашата машина да пренапишат целия си код, за да използват вашия API; те могат просто да добавят прагма

Сигурно има още, които съм пропуснал. Въпросът е, че получавате много безплатен код и безплатна функционалност с API. Ако погледнете внедряването на re::engine::PCRE, за например, всъщност е доста кратък (‹ 400 реда XS код).

Алтернативи

Ако просто търсите по-лесен начин да внедрите своя собствена машина за регулярни изрази, разгледайте re::engine::Plugin , което ви позволява да напишете вашата реализация на Perl вместо на C/XS. Имайте предвид, че има дълъг списък с предупреждения, включително няма поддръжка за split и s///.

Като алтернатива, вместо да прилагате напълно персонализиран двигател, можете да разширите вградения двигател, като използвате претоварени константи, както е описано в perldoc perlre. Това работи само в постоянни регулярни изрази; трябва изрично да конвертирате променливи, преди да ги интерполирате в регулярен израз.

person ThisSuitIsBlackNot    schedule 26.07.2015