ruby-mine

Zeit für den Myntax-Mittwoch! Und zwar geht es um

Heredocs - oder - Code in der 2. Dimension

So sieht ein Heredoc aus:

mein_komischer_string_mit_komischen_zeichen = <<ende
  Mit "komischen Zeichen" meine ich '
  S\\\\o/w(a`s.
ENDE

Man benutzt Heredocs, um mehrzeilige Strings oder Strings mit sehr vielen Sonderzeichen oder beliebigem Text zu erzeugen. Im letzten Kapitel ging es ja um Fancy Strings, die einen beliebiges Zeichen als Begrenzer erlauben. Heredocs erlauben nun beliebige Strings als Begrenzer von Strings.

Jetzt noch ein praktischeres Beispiel:

def make_stylesheet css, in_tag = false
  sheet = css.stylesheet
  sheet = <<-CSS if in_tag
<style type="text/css">
#{sheet}
</style>
  CSS
  sheet
end

Nett, oder? Ich glaube, genau für sowas sind Heredocs gedacht. Kommen wir zur

Syntax (Oberfläche)

Das letzte Beispiel macht deutlich, dass Heredocs ein ganz besonderes syntaktisches Element sind: Obwohl sie ein einzelnes Token darstellen, sind sie aufgeteilt in Kopf (<<-CSS) und Rumpf (Inhalt). Zwischen Kopf und Rumpf kann Code stehen, aber beide Teile sind offenbar magisch miteinander verknüpft. Dazu später mehr.

Heredocs sehen so aus:

• Jedes Heredoc beginnt mit dem zweifachen Kleiner-als-Zeichen ("Double less"). Das führt zu einer Mehrdeutigkeit mit dem Shift-Left-Operator: 2 << 2 == 8. Darum erkennt Ruby Heredocs nur dort, wo ein Wert und kein Operator erwartet wird: a = 2; p(a <<a) liefert 8. Danach darf außerdem kein Leerzeichen folgen.
• Optional folgt dann ein Minus-Zeichen. Es bewirkt, dass das Schlusszeichen nicht unbedingt am Anfang der Zeile stehen muss. Man kann Heredocs auf diese Weise besser im Code einrücken. Führende Leerzeichen im Inhalt werden aber dennoch nicht gefiltert.
• Nun folgt das Schlusszeichen, bis zu dem gelesen werden soll. Erlaubt sind /[A-Za-z0-9_]+/. Typischerweise wählt mal ein Wort in GROSSBUCHSTABEN, vermutlich, um das Heredoc hervorzuheben. Der langweilige Klassiker ist hier <<EOF (End of File). Beliebige andere EO*-Varianten sind auch oft anzutreffen. Aber ich denke, man sollte sich hier etwas mehr Mühe machen und die Heredocs benennen. Der Type des Inhalts (YAML, CSS) bietet sich an, oder auch ein richtiger Name, der den Verwendungszweck angibt (TABLE_TEMPLATE, USAGE, LICENSE). Macht die Welt ein wenig bunter und benennt eure Heredocs ordentlich. Ab jetzt werden ich das Schlusszeichen einfach als "Name" des Heredocs bezeichnen.
• Der Name des Heredocs kann in Quotes eingeschlossen werden. Zur Wahl stehen <<'Single Quotes', <<"Double Quotes" und <<`Backticks`. Sie bewirken, dass der Inhalt des Heredocs so behandelt wird, als stände er in diesen Anführungszeichen; <<'YAML' wird nicht interpretiert, <<"Dynamisch erzeugte Methode" dagegen schon, und <<`MEIN_SHELL_SCRIPT` wird vom System ausgeführt.
• Zu meinem großen Bedauern gibt es keine <</Regexp-Heredocs/x, obwohl sie hier besonders nützlich währen.
• Zwischen den Quotes können, wie gesehen, beliebige Zeichen stehen. Vorsicht: Diese Namen sind keine echten Strings, hier wird nichts interpretiert und Zeilenwechsel können auch nicht vorkommen. <<"\t" wartet bis zu einer Zeile, die nur die beiden Zeichen \t enthält, und nicht etwa auf einen Tabulator.
• Das Heredoc beginnt in der Zeile, die auf den Kopf folgt. Dagegen kann man absolut nichts tun, auch wenn man einen String am Ende der Zeile offen lässt oder ähnliches.
• Der Inhalt wird beendet, wenn eine Zeile gefunden wird, die nur den Namen enthält. Der Minus-Modifier erlaubt Leerzeichen und Tabulatoren vor dem Namen, aber nicht danach!
• Wird der Name nicht gefunden, erzeugt Ruby einen Syntaxfehler und gibt die Zeilennummer an, in der das Heredoc begann.

Heredocs ohne Anführungszeichen werden interpretiert. Die Benutzung von <<"Doppelten Anführungszeichen" ist also nur nötig, wenn man Sonderzeichen im Namen benutzen will oder explizit sein möchte. Ansonsten sollte man immer die einfachen Quotes verwenden, wenn man keine Interpretation braucht. Zur Sicherheit.

Syntax (deep)

Wenn ich ehrlich bin (Ruby-Minenarbeiter sind immer ehrlich!), habe ich mich vor diesem Artikel gefürchtet. Heredocs (von englisch Here Document - "Hier Dokument") sind wirklich kompliziert, wenn man sie vom Standpunkt des Interpreters betrachtet. Wie funktioniert das eigentlich, dass man nach dem Namen noch Code schreiben darf?

Ich übersetze hier mal aus der Dokumentation zum Rdoc-Lexer, also die Klasse, die sich darum kümmert, Ruby-Code in einzelne Token zu zerlegen:

Hier muss auch Here-Document-Umleitung erlaubt sein. Dieses kleine Juwel kommt ins Spiel, wenn der Lexer auf ein Here Document stößt. An diesem Punkt muss der Eingabestrom im Prinzip in zwei Teile zerlegt werden: Einen, um den Rumpf des Here-Documents zu lesen, und einen anderen, um den Rest der Eingabezeile zu scannen, in der das Here-Document beginnt. Zum Beispiel könnte man so etwas haben:

do_something(<<-A, <<-B)
  stuff
  for
A
  stuff
  for
B

Wenn der Lexer auf das <<A stößt, liest er die Zeile bis zum Ende und behält sie im Speicher. Dann liest er den Rumpf des Here-Documents. Wenn er fertig ist, liest er den Rest der Originalzeile, überspringt dann aber den bereits gelesenen Rumpf.

Tief durchatmen. Kopf nach rechts drehen, um 90°. Heredocs sind vertikale Strings! Sie gehen in die Tiefe, während der eigentliche Code linear weiterläuft. Es ist wirklich am einfachsten, sich Heredocs als Strings in der 2. Dimension vorzustellen.

Missverstanden

Zum Abschluss noch eine Kuriosität. Sehr viele Leute scheinen Metaklassen-Blöcke so einzuleiten:

class <<self

Dieses Ruby-Idiom ist ja bekannt. Aber wieso zur Hölle so eine hässliche Zeichensetzung, die doch nur den Editor durcheinanderbringt? Das ist kein Heredoc. Bitte so:

class << self

Weiterlesen

• Wikipedia (englisch); wieder ein Beispiel dafür, dass es in Wikipedia wirklich zu jedem Scheiß sehr vielen Themen einen Artikel gibt.
• Heredocs in Linux (gilt vermutlich für alle *nix-Systeme)
• Heredocs in Perl und KwikiCode
• Heredocs in PHP
• Mein altes Obfuscation-Rätsel: "self << class" im deutschen Ruby-Wiki