ZTシステムの優位性がむしろ不利益となる

生存期間が過ぎたオブジェクトは通常そのオブジェクトを生成した親オブジェクトによって削除され消滅する.このような手続きをノーマルな終了処理と呼んでおこう.しかし,場合によってはそのオブジェクトの状態に関わりなくいきなり削除される場合もあり得る.このような措置をアノーマルな終了手続きとする.制御された解体とはこのようなアノーマルな終了を含めてすべてのオブジェクトがシステム整合的に秩序立って解体されるようなプロセスである.このために必要な要件はほぼ明らかになった.つまり,①すべての終了処理は事前処理として実行されなくてはならない,②アノーマルな終了の場合にも①の手続きが実行されることが保証されなくてはならないという二点である.

しかし,ここにはややパラドクサルな問題が存在する.①の手続きはオブジェクトQの息がまだ残っている間にQの存在を仮定せずに整合する世界の状態を準備する.つまり,Qがいてもいなくてもよい状態にするというのが①の手続きだ.それならば,①の手続きを開始する以前にQの存在を抹消してしまえばよいのだが,そういう訳にもゆかないという事情がある.つまり,Qの関係者は親オブジェクトPだけではない…親オブジェクトとの接続を切断してしまうと,Qの世界における位置は不定となり,どこからもQを探すことはできなくなる.従ってP⇒Qの関係の切断は終了手続きの最終段階で実行されなくてはならない.ただし,P⇒Qという関係の存在は事後の世界像と矛盾する.つまり,終了手続きが進行している期間中はまだ事前処理は完了していない.

たとえば,リストPからQを削除する手続きを考えてみよう.リストPは①リスト先頭要素,②リスト末尾要素,③現リスト要素という3つのパラメータを管理しているとする.②と③は参照関係だが,①は先頭要素への接続リンクだ.このとき,削除対象のQが先頭要素であった場合には①は現状のまま(手続きの最終段階まで)存続することになり,「事前に事後の世界を実現」したことにはならない.

このような事象の起こる原因は「接続と参照の混用」にあると考えられる.①が参照であれば,Qが存命している間にも別のオブジェクトを参照するように付け替えることは可能であり,そうすればこの問題も解消する.つまり,リストにもう一つの参照用スロットを追加することで問題は解決する.「接続と参照の混用」を回避するもう一つの方法としては,パラメータを関数化するということも考えられる.

たとえば,toplistという変数の代わりにtoplist()という関数を用いれば,モードによって返す値を切り替えるなどのこともできる.あるいは,関数内部に静的変数を置いて,事前に値を設定しておくなどのことも可能である.しかし,どちらの方法もあまり望ましいものとは言えない.モードや内部変数の使用には誤用のリスクもあり,プログラムのメンテナンスを難しくする要因となりがちだ.

「接続と参照」を完全に分離することは可能だろうか?通常(世間一般)のプログラムには「接続」という観念は存在せず,リンクと言えばすべて「参照」のことを意味すると考えられるから,「接続と参照」を完全に分離することが必要であるとすれば,ZTシステムの優位性がむしろ逆に不利益として作用していることを認めることになる.(こんなはずではなかったのだが…)ここでは暫定的にtoplistを関数化し,もし,リスト先頭要素が「脳死状態」と判定された場合には,次ノードを返すようにしておくことにしよう.

▲ZTシステム構成図7.ZELを直系親族図で起動したあと,#201 noduleでソートしてTOPOLOGY::CountMultiCardで停止した.基準ノードの多重出現が起きている.

image

確かにそのようだ.この不良は少なくとも現在インストールされているリリース版で起きている.この不良が最近作り込まれたものか,それともかなり前から起きていたのかどうかについては不明だが,とりあえず保留して先に進むことにする.まず,上記した指針に従って,toplistの関数化から始めることにしよう.

上記操作後,アプリ終了してNAMEBOX::CancelBetweenTwoで停止した.(rightbox->IsRightHandBox())という理由だ.カードが関係する両手に花関係をキャンセルしようとしているが,cancelBetweenTwoを実行したにも関わらず状態が変化していないというエラーだ.この人名枠の結婚チェーンの先頭結婚枠の属性RIGHTHANDBOXが落ちていないという意味だ.結婚チェーンの先頭枠が変化している.処理対象となっているカードは両手に花の左手本人カードだ.BTW解除の対象となっている結婚枠は右手本人の結婚チェーン上にある.BTW解除によってこの結婚チェーンが変化することがあり得るのかどうか?という点が問題だ.BTW解除した直後の状態をSUWで見られるだろうか?ちょっと無理なようだ.すでにCloseFamilyBaseでINITIALSTATEまで落ちている.ファイルを開いたときの状態を見てみよう.

image

SIMPLEGRAPH(グレーのカード)は結婚を10持っている.一つはnoduleを子どもとする単身婚でそれ以外はすべてこのボックス内にある.このボックスではSIMPLEGRAPHは配偶者ポジションにあるため,通常の多婚歴のように1本の結婚線で連結することができないため,BTWを使った「姉妹重婚」の形態になっている.SIMPLEGRAPHの結婚はgraph1との間に子どもがいる他はすべて子なしのため不可視になっている.graph1との結婚が#468, graph2との結婚が#216,graph3との結婚が#202…のようになっていて,最初の#468だけが普通の結婚でSIMPLEGRAPH(1)は配偶者としてgraph1の左に表示されている.それ以外の結婚枠はすべてBTW右手枠として,左手本人の下にある.

不良の原因は単純だ.NAMEBOX::CancelBetweenTwoの下位関数cancelBetweenTwoが(PHASE <= CLEARTABLE)では無動作で復帰するようになっているからだ.2020年11月22日のログに「以下の関数はCLEARTABLEフェーズ以下では無動作で抜けるようにした.これらは比較的規模の大きな関数で理論的には不可能ではないとしても,いま直ちに対処するのは難しい.」として,①NAMEBOX:RetrieveGhostと②MARGBOX::cancelBetweenTwoを挙げている.⇒CancelBetweenTwoも同様に扱うようにした.

▲HOMEキーが効かない 逆に分身カードをクリックすると本人カードにジャンプしてしまう 

上の図面を開いている状態で系図画面設定で人名枠高をインクリメントしてGetGeneBoxで(gnum < 0)により停止した

NAMEBOX:Dispose→getSameGeneBoxからの呼び出しだ.getSameGeneBoxを呼び出しているのはNAMEBOX::Disposeだけだ.エラーが発生しているのは系統並び替えの入口でClearTableを実施しているところだ.この段階ではsamegeneはまったく使われていないはずだが,NAMEBOXから見るとどこから参照されているか,ないし参照されていないのか?を判断することができないので,getSameGeneBoxに問い合わせしようとしているのだが,当然失敗する.基本世代枠の操作では物理世代番号(確定世代番号)が使われる.

系列枠の垂直位置関係が決定するまではこの値を確定することはできない.ClearTableではもちろん系列枠は存在していないので,不定としか言えない.⇒GEN2DEVで系列枠が存在しないときはFARFUTUREを返すようにした.⇒これで取り敢えずエラーは解消したが,抜本的に解決するためには,チェーン操作を世代番号に依存するのではなく,トポロジーによって決定できるようにする必要がある.これにはチェーンをリング化する以外方法はない.

▲姉妹重婚のときは左手本人から出る1本の連結線で表示した方がよい

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA