宇田川によるソフト リンク(シンボリック リンク)の訳語。希哲11年6月25日考案。対義語として密輪結も考案。
第二次知番改良,早朝出振るいの成功で第零番節の削除は完了。作業は円滑に進み,再稼動後も安定して軽快に動いている。
やはり,これだけでも大分すっきりして見える。見た目だけでなく,8日の方針転換からわずか7日間で,知番周りの実装も様変わりした。第零番節を扱っていた交度や出場の定義を削除したことで可読性が大きく向上し,出与えとしても軽量化出来た。12日の整理も大きく貢献して,出場周りの保守性は劇的に改善した。これは「第零番節の省略」だけではありえなかったことだ。
さらに,出場との関わりが深い機能実装や高速化の作業方針にも良い影響を与えている。「第零番節の削除」への転換は全体として大成功と言っていいだろう。
第零番節は単に無視するようになったため,これまで通り第零番節付きの知番も扱える。とりあえず輪郭の正規 URL は第零番節無しで設定出来ているので転送などは後回し。
自我アイコンの分割格納方式への移行もいったん後回しにした。現状,K#F85E/
への疎輪結 K#9-F85E/
を作って,保存時・握接時に一律 9-
付きで処理するようにしているだけ。
分割格納方式への移行作業前に,知番譜類における拡張子の扱いについて検討して終了。
これまでの自我台録(/kn/K#F85E/
)には無接尾子の譜台がいくつかあるが,譜類添付機能に合わせ,これを全て拡張子付きに練名することを考えていた。
そもそも知番譜類は,知番を譜類名にしてデルン上で管理する譜類管理手法として始まり,デライト開発が本格化してからこの経験を元に拡張子毎の添付譜類という概念が固まった。
当初は一貫性の観点からむしろ無拡張子を基本に考えていたため,初期の知番譜類には無拡張子の実体に拡張子付きの疎輪結を置いているものがある。ただこれは煩雑な上に,Windows 仮想機で上手く扱えない問題があったため次第にやらなくなった。以後,普通に拡張子を付けることが多くなった。
いっそのこと,全て拡張子付きにして譜類添付機能との整合を取るかと考えたわけだが,全ての譜類に適当な拡張子があるわけではなく,必ず指定するとなると煩雑化の恐れがある。適当な拡張子がなければ .unk
のような特殊な拡張子を使う,台録なら .d
接尾子を使うなど仕様も複雑化する。
仮に無拡張子の知番譜台を空けたところで,その使い道があまり無いという問題もある。本来輪郭情報を置くのが適当なところだが,エクスポート機能等では閲覧・編集の都合から .oln
を使うことを決めている。分割格納方式を採用したことで利便性はいずれにせよ知機駒手で補うしかなくなっているので,実体の場筋に利便性を持たせる必要もなくなった。
譜類添付機能やエクスポート機能はあくまでも知番譜台の応用として,無理に統合せず,一定の相互運用性を確保しておくに留めるのが最善と結論付けた。
ただ,拡張子用の疎輪結だけは問題なので普通の拡張子付きに練名しておくことにした。
+ 接尾子を使った台録構造について見直した結果,これまで必ず置いていた各実行譜類への疎輪結のみ「必要に応じて」とすることで概ね現状維持となった。
アンダースコア略記法の廃止により,今後は kn+/foo+/bar.sh
のような台録構造で副駒手を管理することになる。いっそのことこの + 接尾子も廃止していいかと思ったが,kn+/foo
という無拡張子疎輪結を使うことでスクリプト実装(.sh
)とバイナリ実装(.x
)の切り替えが容易になるという狙いがあり,これはこれで捨て難い。設定譜類より直接的で分かりやすいし,最上位は kn
と kn+/
になるのが自然なのでそれに整合的でもある。
将来的に膨大な副駒手を追加することを考えて持たせた柔軟性だが,これまでの実装では無拡張子疎輪結を通して副駒手を探索していたため,常に各副駒手に疎輪結しておく必要があり,スクリプト実装しかない現状ではただ煩雑なだけだった。これを省けるようにすれば柔軟性は維持しながらかなり見通しが良くなる。