Schlüsselwörter Required und NoValue
In der vorigen Sprachversion von Intent konnten Regeln ohne Vorgabewert erstellt werden. Es kam dann während der Laufzeit zu einem Fehler, wenn der Evaluator feststellte, dass kein Wert berechnet werden konnte. Dieses Problem trat häufig bei Parameterregeln auf. Diese gaben lediglich zurück, dass der Parameter nicht bereitgestellt wurde. In Sprachversion 3.0 von Intent sind keine solchermaßen leeren Regeln zulässig. Stattdessen werden zwei allgemeine Schlüsselwörter verwendet: Required und NoValue. Required führt bei der Auswertung zu dem Fehler required value not supplied (ein erforderlicher Wert wurde nicht bereitgestellt), und NoValue wird als NoValue zurückgegeben (es wird kein Fehler generiert). Erforderliche Parameter MÜSSEN bereitgestellt werden, damit der Bauteil-Editor die Erstellung des Bauteils erlaubt.
Dieser Unterschied zwischen den beiden Sprachversionen bedeutet jedoch, dass das Konvertierungsprogramm IntentUp bei Vorfinden einer leeren Regel die Werte Required und NoValue nicht korrekt zuordnen kann. Da die Intention der leeren Regel meist nicht klar ist, fügt IntentUp statt dieser einfach beide Schlüsselwörter ein [[Required|NoValue]]. Diese Syntax kann nicht kompiliert werden, sodass jeder Versuch, das Design zu laden, fehlschlägt. Die Datei muss dann manuell korrigiert werden. Dabei ist herauszufinden, ob für die jeweiligen Regeln Required oder NoValue verwendet werden muss.
- Kanonische Werte sind fast immer erforderlich (Required).
- Bei einer Testfunktion, die nach NoValue sucht, sollte hingegen NoValue verwendet werden.
- Ein Parameter, der nur ein möglicher Aktivierer einer Gruppenregel ist, sollte in der Regel nicht Required sein (Required bedeutet, er muss bereitgestellt werden).
- Wenn keiner der oben genannten Grundsätze zutrifft, verwenden Sie Required und führen einen Test durch. Passt Required in diesem Fall nicht, so wird das in der Regel sofort offensichtlich.
Regeln für die Entwicklung von Sprachelementen
Regeln für die Entwicklung von Sprachelementen können nicht konvertiert werden. Diese Regeln bestehen meist aus Zeichenfolgeliteralen, die mit berechneten Zeichenfolgen kombiniert wurden. Die Ergebnisse werden Intent dann als Sprachquelle bereitgestellt. Sämtliche dieser Regeln müssen in die neue Syntax konvertiert werden. Beispiel:
Syntaxspezifische Regeln
Benutzer verwenden für die Analyse von Sprachelementen gelegentlich Zeichenfolgesuchfunktionen (z. B. Referenzketten). Da sich die Syntax von Referenzketten geändert hat, schlagen diese Regeln fehl.
Anweisungen im Vergleich zu Ausdrücken
In früheren Sprachversionen von Intent waren alle Sprachkonstrukte Ausdrücke, die einen Wert zurückgaben. In Sprachversion 3.0 von Intent sind viele dieser Konstrukte nun Anweisungen, die keinen Wert zurückgeben, bzw. sie können sowohl als Anweisung als auch als Ausdruck formuliert werden. Bei der Verwendung als Anweisung wird jeglicher Rückgabewert ignoriert.
Da der Ausdruck If-then-else bislang immer einen Wert zurückgegeben hat, führte er gelegentlich auch zu toten else-Verzweigungen, nämlich dann, wenn die Anweisung aus Effektgründen anstatt zur Rückgabe eines Werts verwendet wird. Hier ein Beispiel:
Die else-Klausel wird hier überhaupt nicht verwendet. Dieses wird wie folgt konvertiert:
IntentUp versucht, solche Probleme zu erkennen und so umzuschreiben, dass das neue If-Then-Konstrukt verwendet wird. Wenn dies automatisch aber nicht möglich ist, müssen Sie es wie folgt manuell korrigieren:
Deklarationen und Typen
In der Sprachversion 3.0 von Intent müssen alle lokalen Variablen deklariert werden. Dies war in früheren Versionen nicht erforderlich. Aus diesem Grund fügt IntentUp allen lokalen Variablen in Anweisungsblöcken Dim-Anweisungen hinzu. Da der Typ dieser Variablen unbekannt ist, werden sie mit dem Typ Any angegeben. Solche Deklarationen verdecken häufig die Ursache von Problemen in einer Anwendung, weshalb wir empfehlen, Any durch spezifische Typen zu ersetzen, sofern diese bekannt sind.
Anmerkungen zu bestimmten Elementen
Loop
Die Sprachversion 3.0 von Intent verfügt nicht über ein einheitliches Loop-Konstrukt, das dem Loop-Ausdruck der früheren Versionen entspricht. Stattdessen stellt sie verschiedene iteration-Konstrukte bereit, die in verschiedenen Situationen angewendet werden können. IntentUp versucht nicht, herauszufinden, ob ein Loop in eines der neuen iteration-Konstrukte konvertiert werden kann. Stattdessen unterstützen IntentUp und die Sprachversion 3.0 von Intent eine kompatible Schleifensyntax, die eine präzise Zuordnung alter Schleifen zu Code ermöglicht, der auf die gleiche Weise funktioniert.
Ref
Die Funktion Ref verwendet zur Darstellung einer Referenzkette eine Zeichenfolge. Die Syntax für Referenzketten hat sich geändert. Aus Kompatibilitätsgründen wird in der Sprachversion 3.0 von Intent jedoch noch die Syntax früherer Intent-Sprachversionen mit Doppelpunkten akzeptiert. Anweisungen wie:
werden daher wie folgt konvertiert:
Sie sollten jedoch nach wie vor korrekt funktionieren (vorausgesetzt, wayToUpdate ergibt eine Zeichenfolge). Für andere Funktionen, die Teile der Sprachquelle als Zeichenfolgen verwenden, trifft dies jedoch nicht zu.
Unärer Minus- bzw. Not-Operator
In früheren Versionen von Intent konnte das unäre Minuszeichen (-) gleichermaßen für numerische Werte als auch für Boolesche Werte verwendet werden. In der Sprachversion 3.0 von Intent werden hierfür zwei verschiedene Operatoren verwendet. Das Minuszeichen bleibt numerischen Werten vorbehalten, während für boolesche Operationen der logische Operator NOT verwendet wird. Da der Translator den Typ der Werte meist nicht kennt (dies ist nur der Fall, wenn es sich um ein Literal handelt), versucht es nicht, den Operator zu konvertieren. Wenn es sich beim Operanden um einen binären Booleschen Ausdruck handelt, wird der Operator in NOT konvertiert.
Nachstehende Kommas in Listen und Argumenten
In früheren Versionen von Intent waren nachstehende Kommas und Trennzeichen zulässig. Sie wurden ignoriert. Eine Liste wie {1, 3,} wurde als Liste mit zwei Einträgen analysiert. IntentUp verwendet die ältere Parser-Technologie, sodass solche Listen nach wie vor zulässig sind und ignoriert werden. Dies bedeutet jedoch, dass die Ausgabe keine nachstehenden Kommas enthalten kann, da diese in der Eingabe ignoriert wurden. Anwender, die die Tolerierung nachfolgender Trennzeichen in älteren Versionen gewöhnt sind, möchten wir darauf hinweisen, dass diese nicht nun mehr zulässig sind und zu einem Syntaxfehler führen.