Probleme beim Überladen von Regex-Literalen

(Auszug aus "Reguläre Ausdrücke" von Jeffrey E. F. Friedl)

Zumindest in der Theorie ist das Überladen von Literalen in regulären Ausdrücken sehr mächtig und wertvoll, aber in der Praxis sieht das etwas anders aus. Das Problem ist, dass nur die wirklichen literalen Teile eines Regex-Literals so behandelt werden können, aber schon bei interpolierten Elementen geht das nicht mehr. Bei der Regex in m/($MeinZeug)*+/ wird unsere Funktion RegexLiteralVerarbeiten zweimal aufgerufen, einmal mit dem literalen Teil der Regex vor der Variableninterpolation (»(«) und einmal mit dem literalen Teil danach (»)*+«). (Wenn $MeinZeug ein String ist, der eine Regex enthält, wird der Inhalt nie von der Overload-Routine behandelt.) Weil unsere Funktion aber die öffnende und die schließende Klammer gleichzeitig braucht, setzt sie diesen possessiven Quantor nicht in eine atomare Klammer um.

Beim früheren \< und \> trat dieses Problem nicht so sehr in Erscheinung, weil diese Sequenzen kaum von interpolierten Variablen unterbrochen werden. Weil aber der Overload-Mechanismus nur Regex-Literale betrifft, werden damit Strings, die reguläre Ausdrücke enthalten, nie verarbeitet (mit Regex-Objekten gelingt dies). Wie wir im letzten Abschnitt gesehen haben, ist es außerdem oft nicht einfach, die Regex vollständig und korrekt zu verarbeiten. Sogar unser einfaches Beispiel mit \> versagt bei einer Regex, die ›\\>‹ enthält, denn damit soll kein Wortende erkannt werden, sondern ein ›\‹ und ein ›>‹.

Es gibt außerdem für die Overload-Routine keine Möglichkeit festzustellen, welche Modifikatoren bei einer bestimmten Regex aktiv sind. Insbesondere beim /x-Modifikator ist das natürlich sehr wichtig, aber es gibt in der aktuellen Implementation keine Möglichkeit, das festzustellen.

Wenn das Overloading benutzt wird, kann man außerdem Zeichen nicht mehr mit ihrem Unicode-Namen eingeben (\N{Name}, siehe Namen für Unicode-Zeichen).

  

<< zurück

vor >>