Aufbau der Schnittstellen

Schnittstellen von Libraries sind dabei in zwei Definitionsmoduln folgender Namensgebung zu finden:

1. Der Libraryname erweitert um den Buchstaben ,,D`` enthält alle Datendefinitionen -- also Typen und Konstanten -- der Library. Dieses Definitionsmodul enthält keine Implementation.
2. Der Libraryname erweitert um den Buchstaben ,,L`` enthält alle CODE-Prozeduren der Library-Aufrufe. Dabei sind alle aktuell vorhandenen Prozeduren der Library enthalten.

In beiden Moduln sind alle Objekte bis zur aktuellen Version 37 deklariert, ab Version 36, der Entwickler-Version, jedoch besonders gekennzeichnet.

Damit lässt sich die bisherige umständliche Verwendung von Schnittstellenmoduln verschiedener Library-Versionen, also beispielsweise Intuition, Intuition34, Intuition36 und so fort, vermeiden.

Allerdings wird die bisherige Anforderung an die vorhandene Mindest-Version einer Library fallengelassen. Der Programmierer ist nun selbst verantwortlich, die Version und den damit vorhandenen Prozeduren-Umfang zu prüfen!

Dafür existiert in jedem Schnittstellenmodul mit den Library-Routinen eine Variable mit dem Namen libraryVersion, mit dem vollem Namen also IntuitionL.intuitionVersion. Diese enthält die Versionsnummer der geöffneten Library. Nach Abfrage dieser Versionsnummer hat der Programmierer folgende Reaktionsmöglichkeiten:

• Er kann das Programm abbrechen, wenn die Library nicht seinen Mindestanforderungen genügt, er also Prozeduren braucht, die nur in höheren Library-Version vorhanden sind.
• Er kann das Programm so schreiben, dass im Falle einer niedrigeren Version nur eine eingeschränkte Funktionalität angeboten wird, indem etwa Menupunkte ausgeblendet werden.

  Dies ist das ähnliche Verhalten wie bei optionalen Libraries, die ebenfalls durch Mehraufwand des Programmierers abgefangen werden können, und das fertige Programm unabhängig der vorhanden Libraries ablauffähig erhält.

Dieses Abprüfen widerspricht etwas der -Philosophie, erleichtert aber die flexible Programmierung ungemein. Ein Beispiel dafür findet sich im Modul WbClone auf der Demo-Diskette.

Für Libraries, die erst ab Version 36 existieren, gibt es ein zusätzliches, drittes Modul OptlibraryL, beispielsweise OptWorkbenchL, das eine optionale Library ohne Implementation darstellt (siehe 5.1.13). Beim Import solcher Moduln ist das Programm auch ohne diese Library lauffähig, allerdings muss vor Benutzung der Prozeduren die libraryBase auf Ungleichheit mit NIL prüfen.

Jede Library ist also durch die soeben beschriebenen Moduln zu verwenden. Eine feinere Unterteilung -- in der Programmiersprache C sind Library-Schnittstellen durch mehrere Header-Dateien beschrieben -- existiert nicht.

Ausserdem existieren implementationlose Moduln, die nur Typen- und Konstantendeklarationen enthalten. Dazu gehören beispielsweise alle Device-Schnittstellen.

Im Gegensatz zu früheren Versionen verzichten wir von nun an, alle Definitionen der Schnittstellenmoduln abzudrucken. Hauptargument dafür ist der mögliche Einsatz von M2Ohm, das dem Programmierer jederzeit die nötige Information sehr schnell verschafft.

Durch die einfache Handhabung von M2Ohm (siehe ) finden wir es nicht mehr angebracht, alle Definitionen abzudrucken. Diese haben in der Zwischenzeit einen riesigen Umfang erreicht. Ausserdem wird meistens nur gerade eine Definition bzw. ein Eintrag nachgeschaut. Und gerade dann ist ein Werkzeug wie M2Ohm schneller und einfacher als ein endloses Blättern in Handbüchern.