Lade...
 

IS Modules

Inhaltsverzeichnis:

InstantScript Module stellen die oberste Ebene der Codeorganisation dar.

 

Dateiinhalt und Modulgliederung

 

Dateien, welche Module enthalten sind wie folgt gegliedert:

// Moduldeklaration

Module(example, HELP("example.htm"))

Synopsis("Beispielmodul", "Example module")
Dictionary(T("Bespiele", "Examples"))

    DO_THIS: DoThis
    SHOW_THIS: OpenWindow(EditWin, 1)

    // Prozeduren des Moduls

    Define(DoThis)
      Var(tmp) // Variablendeklaration
      -> tmp // legt den ersten Wert des Stacks in die Variable
      ... // usw.
    ;

" rel="">
    // Messages, welche das Modul empfangen kann

    DO_THIS: DoThis
    SHOW_THIS: OpenWindow(EditWin, 1)

    // Prozeduren des Moduls

    Define(DoThis)
      Var(tmp) // Variablendeklaration
      -> tmp // legt den ersten Wert des Stacks in die Variable
      ... // usw.
    ;

 

// Fensterdeklarationen (1-n)

Window(EditWin, 0, 35, 800, 170, T("Beispiel", "Example"))
    // Messages, die das Fenster empfangen kann

    SHOW_THAT: LoadObjects
" rel="">

    // Messages, die das Fenster empfangen kann

    SHOW_THAT: LoadObjects

{

  // Inhalt des Fensters
  Menu
  {
    ... //usw.
  }
}

 

Hinweis

Anhand der Klammerung ist zu erkennen, dass die Fensterdeklarationen nicht innerhalb der Moduldeklaration steht. Wieso gehören die Deklarationen zusammen? Dies ist per Konvention geregelt: Fensterdeklarationen gehören zu einem Modul, wenn sie direkt nach der Moduldeklaration stehen. Werden in einer Datei zwei oder mehr Module deklariert, muss sichergestellt sein, dass die zugehörigen Fensterdeklarationen an der richtigen Stelle stehen.

 

Klassenanalogie

 

Die InstantScript Module verhalten sich in vielerlei Hinsicht wie die Klassen einer objektorientierten Sprache:

  • Module sind global ansprechbar, d.h. Module können von überall her aufgerufen werden (anonym oder direkt)
  • Module können abgeleitet werden, d.h. es gibt Vererbung
  • Module haben einen eigenen Variablenraum und damit auch einen eigenen Stack.

Hingegen kann man InstantScript Module nicht instanziieren, d.h. sie sind statisch und damit singulär.

Voneinander abgeleitete Module teilen sich einen Variablenraum, d.h. es kann beliebig auf die Elemente zugegriffen werden. Hingegen ist der Zugriff eines Moduls auf den Variablenraum eines anderen Moduls, welches nicht in der gleichen Vererbungshierarchie liegt nicht möglich. Dasselbe gilt - mit einer Ausnahme - für den Aufruf von Prozeduren. Diese Ausnahme besteht dann, wenn eine Prozedur explizit als CodeProvider gekennzeichnet ist.

 

Funktionsweise

 

Module besitzen eine interne Abbildung. Diese ist von aussen (sprich von einem anderen Modul aus) nicht zugänglich.

Module

  • Sektion Messages
  • Sektion Prozeduren
  • Sektion Fenster

Die Sektion Messages definiert, auf welche Messages ein Modul reagiert. Fehlt diese Sektion, ist dieses Modul nicht aufrufbar.

Die Sektion Prozeduren beinhaltet beliebig viele Prozeduren, welche sich gegenseitig aufrufen können. Ruft eine Prozedur eine Prozedur auf, die hinter der aufrufenden Prozedur steht, muss dem Parser die aufgerufene Prozedur vorab deklariert werden.

Die Sektion Fenster 

.

Module lassen sich gliedern in Messages, Prozeduren, Fens 

Message

 

Module können nicht direkt Prozeduren anderer Module aufrufen. Der Aufruf kann aber trotzdem erfolgen, und zwar indem das aufrufende Modul eine Message absendet, die vom empfangenden Modul entgegengenommen wird.

 

Alles ist private: Ebenfalls kann man auf die Elemente der Module (Prozeduren, Fenster, Variablen und Konstanten) nicht direkt zugreifen. Ein Modul kann mit einem anderen Modul nur über den MessageBus kommunizieren, dh. indem ein Modul einem anderen Modul eine Message sendet.

 die Prozeduren der Module nicht direkt aufrufen oder die Werte von Variablen 

CyberEnterprise Referenz