Oberonsのモジュールは、コンパイル、ロード、およびリンクの単位であるだけでなく、カプセル化メカニズムでもあります。 接続された（インポートされた）モジュールのエンティティにアクセスする場合、このモジュールの必須の資格が必要です。 たとえば、モジュールAがモジュールBをインポートし、その変数vを使用する場合、この変数へのアクセスはBvの形式である必要があります。これにより、ファイル接続シーケンスとコンパイラーの動作に応じて、非モジュール言語で同じ名前のまったく異なるエンティティを使用する追跡困難なエラーの数が減少します。
既に述べたように、Oberonsのカプセル化もモジュールの概念に基づいています-モジュールで宣言されたすべての型は相互に透過的であり、外部クライアントはアクセス指定子を介してモジュールエンティティにアクセスします。 現在、Active Oberonには次のアクセス指定子があります。
*「フルアクセス」修飾子-識別子にはアスタリスク（*）が付いています。
*修飾子「読み取り専用アクセス」-識別子にはマイナス記号（-）が付いています。
修飾子が欠落している識別子は、外部クライアントでは使用できません。
例：
TYPE Example* = RECORD a*, b-, c : LONGINT; END;
モジュールの外部にエクスポートされたレコードタイプExample1について説明します。 フィールドaは、型が宣言されているモジュールのクライアントに対する読み取りと書き込み、フィールドbは読み取り専用、フィールドcは外部クライアントから隠されています。
MODULEキーワードの後に指定されたモジュールの名前（結果のオブジェクトファイル）は、たとえばモジュールの実装を分離するために使用されるファイル名と一致しない場合があります。 このメカニズムは、条件付きコンパイルディレクティブメカニズムの代わりに使用できます-常に既知の固定名でモジュールを接続し、ビルドツールは、さまざまなOS、プロセッサなど、アセンブリ条件に従って必要なモジュールを生成します。
Active Oberonでは、プラグイン（インポートされた）モジュールはエイリアスを持つことができ、異なるモジュールは同じエイリアスを持つことができ、一種の名前空間または擬似モジュールを形成し、名前空間エンティティはその名前でアクセスでき、実際のモジュール名は利用できません。 このような名前空間内のエンティティの名前は重複してはなりません。
歴史的に、Oberonオペレーティング環境は通常、モジュールを動的にロードおよびアンロードするためのインターフェースを提供しますが、Pow！のように静的リンクは可能です。 またはOO2C。 言語自体は、モジュールインポートセクションとモジュール初期化セクションのみを提供します。 実装によっては、モジュールのファイナライズセクションもありますが、一般に、ランタイム環境は、モジュールがアンロードされたとき、または静的バインディング中にプログラムが終了したときに自動的に呼び出されるファイナライザープロシージャを登録するためのインターフェイスをプログラマに提供します。
Active Oberonの典型的なモジュール構造：
module Name; import Modules, ....; procedure Finalize*; begin ... end Finalize; begin (* *) Modules.InstallTermHandler(Finalize); (* *) ... end Name.
（はい、Active Oberonでは、キーワードは大文字だけでなく小文字でもかまいません。セットの選択は、モジュールの最初の重要な識別子であるMODULEキーワードの記述形式に従って実行されます。小文字で記述する場合、モジュールのすべてのキーワードも小文字の場合-MODULE、その後大文字）
モジュールが動的にロードされる場合、他のモジュールのインポートセクションからモジュールへのリンクがない場合にのみアンロードできます。 アンロードは逆の順序で実行する必要があります。 OS A2でのモジュールのアンロードは、SystemTools.Freeコマンドによって実行されます。このコマンドは、アンロードされたモジュールのリストを受け入れ、SystemTools.FreeDownToは、すべての（再帰的に）参照するアンロード後にアンロードされるモジュールのリストを受け入れます。
オペレーティング環境はモジュールをアンロードしようとしないため、プログラマーはアンロード時間（必要なものに応じてすべてを含む）を選択できます。これは、動的ロードにはプラス以外の重大な欠点があるためです。また、ユーザーによってアンロードされ、ユーザーが設定したコールバックなどが残り、例外的な状況が発生します。 なぜなら、星の王子さまが言ったように、「朝に起きて、洗って、身をかがめて-すぐにあなたの惑星を整頓するという、とても堅実なルールがある」からです。 つまり、コールバックを指示した場合、それらを削除する必要があります。これは、モジュールのファイナライザーで行われます。 手続き型変数のデフォルト実装を作成することをお勧めします。スタブは、そのような変数が配置されているモジュールの初期初期化中に設定する必要があります。
リンクは、タイプが実装されているモジュールに接続していないモジュール内にある場合があり、正式にはインポートセクションにリンクがないため、参照タイプのインスタンスを処理するのはより困難です。 部分的に、これは工場を使用して戦うことができます。
モジュールがアンロードされると、タイプ記述子を除いて、これらのタイプのインスタンスがシステムに残る可能性があるため、コードとデータがアンロードされます。 VMTのメソッドポインターを含む、タイプ記述子のすべてのポインターはNILに設定されます。 そのようなエンティティにアクセスすると、例外的な状況が発生します。
ご覧のとおり、Oberon-Systemの禁欲的な実装には、開発で考慮すべき長所と短所の両方があります。 ランタイム環境とコンパイラーを複雑にすることを除いて、これらの欠点を解消するための実際の問題はありません。
コミュニティの助けを借りて、Oberonを新しい軌道に乗せることでこれらの問題を解決できる可能性があります。
シリーズコンテンツ
- もっと好き
- モジュール
- 作業環境ETH Oberon