Moment mal, wie lange sitze ich jetzt schon am Rechner und programmiere? Also meine ersten Erinnerungen belaufen sich so ungefähr auf 1987 zurück, d.h. also seit 30 Jahren. In dieser Zeit laufen einem viele Merkwürdigkeiten über den Weg, aber mit Visual Foxpro verbindet mich eine gewisse Hassliebe. Die Altvorderen kennen vielleicht noch dBASE als einen Vorgänger von Foxpro. Als ich anfing mich damit zu beschäftigen, bin ich schon über das Wunder des Stringvergleichs gestoßen, aber jetzt muss ich das mal festhalten. Vielleicht kann ich doch noch andere für diese archäologische Relikt begeistern. Werfen wir mal einen Blick auf den Stringvergleich in Foxpro.
1 2 3 4 | PUBLIC varA PUBLIC varB varA = "Test" varB = "" |
Natürlich begleite ich euch kommentierend auf dieser wunderbaren Reise. Was ist passiert? Wir haben zwei Variablen angelegt. Foxpro arbeitet grundsätzlich mit untypisierten Variablen. Solange ich einer Variable keinen Wert zuweise, geht der Interpreter davon aus, dass es sich um einen Boolschen Wert handelt. Interpreter? Ach so, Foxpro erstellt beim Übersetzen einen Bytecode, der zur Laufzeit interpretiert wird. Kommt euch bekannt vor? Tja, so ziemlich alle Entwickler, die an Foxpro gearbeitet haben, landeten irgendwann im .NET-Entwicklungsteam.
Das Blöde an diesen Variablen ist, dass man sie nicht deklarieren muss. Hätte ich noch ein
1 | varC = "leer" |
hinzugefügt, hätte Foxpro nicht mal was beim übersetzen gesagt, sondern wäre davon ausgegangen, dass es sich um eine lokale (private) Variable handelt. Eine herzerfrischende Quelle für Laufzeitfehler. Aber weiter mit dem Stringvergleich.
1 2 | ? varA = varB && --> liefert true ? varA != varB && --> liefert false |
Der C/C++/C#-Entwickler werden vielleicht bei der ersten Anweisung lachen, weil es wie eine Zuweisung aussieht. Nein, es ist ein Vergleich. Das sollte spätestens bei der zweiten Anweisung klar sein. Aber warum sollte das Wort „Test“ und eine leere Zeichenkette übereinstimmen? Begründung: Foxpro bzw. auch schon seine Vorgänger arbeiten wie in der Tabelle so auch im Speicher.
Anders als beim SQL-Server arbeitet Foxpro Datensatz basiert. Statt
1 | select * from... |
muss ich einen Index setzen und dann mit einem Suchbegriff einen Datensatz suchen. Und die Suche von Foxpro arbeitet initial mit partiellen Zeichenketten. Suche ich mit dem Suchbegriff „Mü“ finde ich Namen wie „Müller“, „Mühle“, „Mühlberg“ usw. Und was finde ich wenn ich mit einem Leerstring suche? Richtig, alles!
Die Foxpro-Entwickler waren nicht dumm und haben der Sprache ein Konstrukt verpasst, dass wir auch aus anderen Sprachen kennen und zum gleichen Erfolg führt.
1 | ? varA == varB && --> liefert false |
Schon klar, aber hää? Wie sieht denn dann der Vergleich auf Ungleichheit aus? Indem man die Operation negiert.
1 | ? !(varA == varB) && --> liefert true |
Sieht komisch aus, ist aber so. Und was haben die Entwickler gemacht, bevor es Foxpro gab? Für die gab es damals einen Schalter, der eine exakte Suche ermöglicht. Auch so kann man Foxpro das richtige Ergebnis abringen.
1 2 3 | SET EXACT ON ? varA = varB && --> liefert jetzt false ? varA != varB && --> liefert jetzt true |
Und genau aus diesem Grund fiel mir ein, dass ich doch irgendwo noch ein altes dBASE IV zu liegen habe. Ich musste einfach ausprobieren, ob das auch damals schon funktionierte. Ja, bis auch das doppelte Gleichheitszeichen, das kam erst später.
