================== Mops 3.3 RELEASE NOTES =================== 訳　渡辺　伸(uw4s-wtnb@asahi-net.or.jp) この『リリースノート』にはMops の前バージョンからの変更点について記述 してあります。すでにMopsをお使いの方はこれをよめば、全てのドキュメント を通して読まなくてもすみます（あるいは巨大なマニュアルをも、です）。この リリースは1998年１０月のものです。６ヶ月以上してからこれを入手しているのでし たら、最新のバージョンをWebサイトでチェックするのが良いでしょう。 まずは私の連絡先です。 ------------------------------------------------------------------------ Mike Hore email: mikeh@zeta.org.au Mops web page: http://www.netaxs.com/~jayfar/mops.html snail-mail: _--_|\ Michael Hore / \ 54 Frederick St, \_.--._* Sydenham NSW 2044, v AUSTRALIA. ------------------------------------------------------------------------ 　Mops 3.3は多分しばらくの間保つのではないかと思います。PowerMopsでの開発は基本的 に完了したと考えているからです。 　お約束しましたように、PowerMopsは今やshared libraryを生成する事ができ、直接的に shared libraryを呼び出す事ができます。 68k MopsとPowerMopsに共通する、その他の新しい特長としてpersistentオブジェクト（訳 注：後述しています）のサポートがあります。 　xcallsファイル（MacOS呼び出しを扱います）はさらに完璧になりました。Appleの Universal Headerからxcallsファイルを生成するプログラムにいくつもの改良--特にマク ロの処理の部分--を加えたからです。 QuickEditもDoug Hoffmanによってバージョンアップされ、PowerMopsをサポートするよう になりました。 このリリースでマニュアルも更新されました。 その他のマイナーな変更として、HandleArrayクラスが使われなくなりました。 HandleListを使えば同じことができるからです。HandleArrayはファイルStruct 1に入れら れ、マニュアルからは削除されました。 修正されたバグ ========== 1. 68k MopsのワードTBoolはmakeintを含むようにしました。以前は含まれていたのですが PowerMopsでは必要ないので削除されていました。条件付きコンパイルにより68k Mopsでは 再び含まれるようにしました。 2.Mopsウインドウ内（またはQuickEdit内）で複数の行をハイライト表示し、enterを押す 事により結果を得る事ができます。以前のバージョンではうまく動作しなかった"\"タイプ のコマンドを含む行でも大丈夫です。 　　新機能 ============ SHARED LIBRARY をコールする(PowerMops のみ) ========================================= shared libraryをコールする方法が改善されました。EXTERNは以前と同様にサポートされ ます。しかし新しい方法のほうがもっと使い易くなっています。 バージョン3.2と同様にしてshared libraryを宣言します。 library MySharedLib (SYSCALLと同様にライブラリ名は大文字／小文字を区別します) 新しいワードであるLIBCALL(故意にSYSCALLに似た名前にしました)で使用するコール名 (call)をすべて宣言します。LIBCALLは次のようにして使用します。 libcall myEntry { parm1 parm2 %parm3 -- result } 　名前つきパラメータの書式ににている事に気がつく事でしょう。浮動小数点パラメータ は"%"が最初につきます。すべてのパラメータと戻り値を指定する必要があります。そうし ないと使用できません（xcallsファイルを利用するSYSCALLとはここが違います。）。しか し、パラメータの文法は通常のMopsのワードの名前つきパラメータと同じです。そのコー ル(call)が浮動小数点を結果として返すのなら、そのように記述してください。 libcall myFloatWord { %parm1 parm2 -- %float_result } 　使用されるライブラリはそれよりも以前に書かれたもっとも近いLIBRARY宣言のもので す。 　返される結果は整数(integer)、浮動小数点(floating)、無しのいずれかです。 これはC/Pascal変換により定義されます。shared libraryでどのように変換されるかを確 認しておく必要があります。どんな言語からも呼び出されるようにつくられているはずで す。 SHARED LIBRARY を生成する(PowerMops のみ) ============================================ 　shared library を新しいinstallダイアログの新しいオプションから生成する事ができ ます。これはinstallの特別な場合として処理されます。アプリケーションもshared libraryのどちらもMops環境から独立して実行できるファイルを生成するものだからです。 　さて、shared libraryのどのワードを外部から使用できるかを指定しなければなりませ ん。これがあなたの作成したライブラリの入り口になります。次のように宣言します。 :entry myEntry { parm1 parm2 %parm3 -- result } ;entry 　これはお馴染みの形式ですね。上記のLIBCALLで呼び出すワードと同じです。文法は基本 的に同じです。パラメータは名前つきパラメータと同じ文法を持つというわけではなく、 これらは本当に名前つきパラメータなのです。これらはmyEntryの定義中でアクセスできま す（もちろん必要ならばローカル変数も定義中で使用できます。） PERSISTENT OBJECTS ================== "Persistent Objects"というのはあなたの作成したプログラムを終了した後もその状態は 残り、次に同じプログラムを走らせたときに再びそのまま使えるものです。つまりこれら は使われていないときもファイルのどこかに存在しなければならないという事です。 persistent オブジェクトをインプリメントするにはオブジェクトを書き出し、また後で読 み込むという処理を実現しなければなりません。 　このことから、persistentオブジェクトを実現するためには、そのオブジェクトをどん な構造であっても一連のバイトデータに変換しファイルとして読み書きできるようにしな ければなりません（serializeと呼ぶことにします）。 わたしたちは正攻法でアプローチしました。これは次の２つのパートから成ります。 １．ファイルの概念を少し一般化しました。READ:,WRITE:メソッドをもちファイル的扱い をするどのクラスも"stream"メソッドを持つ事にしました。この考え方はインターフェイ スとおなじことです。READ:,WRITE:はstream インターフェイスの一部になります。Mops は形式化されたインターフェイスを文法に持ちませんが、考え方は同じです。Mopsではこ れまでは無かったというだけです。 ２．それぞれのオブジェクトは自分自身をどうやって"serialize"するかを知っているもの とします。そのメソッドはSEND:,BRING:とします。どちらもstremオブジェクトのアドレス をパラメータとします。SEND:はlate-boundのWRITE:メッセージをstreamに送るようになっ ています。これによりオブジェクトのバイトデータを書き出します。クラスは、BRING:に より元どおりにできるのであればどのような形式でも選ぶ事ができます。BRING:はlate- boundでREAD:メッセージをstreamに送ります。これによりデータを元どおりのオブジェク トに戻します。 これらのメソッドをすべてのMopsの標準クラスに装備しました。 Objectクラスはもっ とも基本的なものを実装しており、ローカルのivarと配列の書き出しと読み込みを行いま す。単純なオブジェクト（ローカルエリアの外側にデータを持たない）では機能します。 　配列になっていないものとなっているものは別々に書き出します。プラットホームに依 存する問題を回避するためです。PowerPCでは４バイトごとに配列は配置されますが68kで は２バイトごとになっています。ローカル変数ではクロス・プラットホームは保証されて いますのでObjectクラスで十分です。そのばあいにはSEND:,BRINGには別々のものは必要あ りません。 　Handleオブジェクトはローカルエリアの外にデータを持ちます。そのため、Handleクラ スは別のSEND:,BRING:が必要となります。Structのソースファイルを見れば、長さと handleのデータを転送していることがわかるでしょう。Handle自身のほかには変数はあり ません。 ここではHandleに格納されるデータ自身が対象となっています。 　ObjHandleクラスはHandleを継承しただけです。ハンドルによって指されるオブジェクト がそのまま保存されるという事です。これはあまり良い事ではありません。なぜならオブ ジェクトは自分自身を適切な形で保存する手段を知っているべきだからです。そこで文字 情報としてのクラス名とSEND:をオブジェクト自身に送ることにしました。BRING:をすると きにはクラス名を得たら新しいオブジェクトを生成し、そこにまたBRING:を送ります。 （もとの状態を回復するため） 　この方法の良いところはオブジェクトがアドレス情報を持っている必要がなく、Mopsの コンパイラによって元の状態が作り出せること、プラットホームがかわっても大丈夫なこ とです。 　HandleListクラスでは、まず２バイトでアイテム数を送り、それからSELECT:でそれぞれ のアイテムを指定してそこにSEND:を送ります。それぞれのオブジェクトを送るときに間に マーカーを入れています。BRING:は同期が外れていないかどうかをチェックすることがで きます。 　基本的なMopsクラスのSEND:とBRING:のインプリメンテーションはほとんどの要求に答え ることができると思います。もし、あなたが作るクラスに特別な機能が必要であっても、 そこにどうすれば良いか、答えがあるはずです。 persistentオブジェクトのインプリメンテーションの最後のステップです。オブジェクト にSEND:,BRING:が適切に実装されたなら、それをファイルにリンクさせなければなりませ ん。More ClassesフォルダにContainerというファイルがあります。そこにどうするべきか が書かれています。ContainerクラスはFileのサブクラスで、INIT:メソッドでオブジェク トを渡すことができます。OPEN:,SAVE:メッセージをContainerに渡すことにより、 ContainerはBRING:あるいはSEND:メッセージをオブジェクトに送ります。 Containerにオブジェクトを一つだけしかリンクしないのは、Contanierの扱えるオブジェ クト数に制限があるからではありません。オブジェクトは任意の数で任意のクラスのオブ ジェクトの集合であるHandleListでも良いのです。HandleListにSEND:,BRING:が適切に実 装されていることは既に説明しました（任意のクラスからなるオブジェクトのリスト で）。 　OPEN:をContainerに送ると、Containerのオブジェクトはメモリに読み込まれます。 SAVE:を送るとファイルに書き込まれます。もし同時にすべてのオブジェクトがメモリ上に なくても良いのなら複数のcontainerを使用することができます。 　この方法は非常にフレキシブルでほとんどのニーズに十分対応できると思います。 -------------------------------------------------------------------- As always, I hope you enjoy Mops! - Mike Hore mikeh@zeta.org.au