型に関する函数と名称空間の関係について,foo が単純型の表現である場合は foo() を変換函数に,複合型の表現である場合は foo_T() を変換に利用し,必要であれば foo:: を関連函数などをまとめる名称空間として利用することを明文化することにした。
もともと,自然にやっていたことではあるが,改めて検証してみると意外に合理的だったことが分かった。
これら規約を Cμ 標準名称空間規約,Cμ 標準譜台規約として管理していくことにした。
s_T
}{n::}{s::}{整合的}{s_T()}{単純型}{n()}{希哲14年1月13日の進捗時限}(27)途中で終了。
もともと,名称空間を切り分けやすくしたい,ADL を効率的に利用するために foo_T を foo:: 以下に入れ,冗長性は use で解決するという方法を取っていたが,これはいまだに有用であるため,据え置くことにした。
一方,これに合わせて foo/ に foo.cl.h を入れる,というような方法は煩雑さの方が大きいため,廃止することにした。これは定義位置ではなく,通称を基準に考えることで整合性を取る。既存の譜類は順次移動させる。
foo:: と foo() が衝突する問題をどう回避するかという課題は Cμ 初期からずっと残っているが,今のところそれほど大きな障害にはなっていないため解決は急がないことにした。
C++ は参照内容によって foo が名称空間か函数か解決してくれるような気の効いた仕組みにはなっていないため,foo を名称空間として利用するか函数として利用するかは設計の問題と考えるしかないかもしれない。
これまで,数値への変換は n() で,文字列への変換は s_T() で行うことが多く,整合的ではない気がしていたが,よく考えると単純型と複合型の使い分けとして合理的だったのかもしれない。s_T には s:: があった方がいいが,n:: の必要性は感じたことがない。
ここしばらく悩んでいた Iti/src/site/ 以下の台録構成で閃きがあった。
ページ用の台録を _pg_/ として,これ以前の台録構成をサイトの分類,これ以後の台録構成をページの分類とする,という方式を編み出した。site/ も,これ以下が自由構成であることを示すために site_/ に改称した。
これにより,example.com/path/to/dir というページは site_/com./example./_pg_/path/to/dir/pg_idx.h のような構造で表現出来る。これまで気になっていた紛らわしさや曖昧さの問題はこれでほとんど解消した。
未実装だが,site_/ と _pg_/ の間をサイト識別子として自動的に利用する方針も決定した。
これを思いついた当初,ドメイン台録は廃止かと思ったが,サイト識別子としてやはり分かりやすいため温存することになった。これもアイデアが無駄にならず良かった。
希哲13年7月11日の開発で site/ 以下を柔軟に構成出来るようにしておいたことが功を奏した。
色々なことが報われた感がある。
ついでに,その台録で index.html に相当するページをどう表現するかも悩み所だったが,これはウェブの伝統を踏襲して pg_idx.h のように表現することにした。これまでは,root の意で pg_rt.h としたり,トップページの意で pg_top.h などとしていたが,分かりにくかったり,厳密に考えると違和感があったりした(インデックスとトップページは必ずしも一致しない)。台録と同じ階層に同名の拡張子付きで,というのも考えたが,これをやると規則が複雑化する。
結局,ウェブ開発者なら直感的に理解出来るインデックスをウェブ用語として援用するのが無難だろう。
Synx Filesystem Hierarchy Standard
旧称 KFHS: Knower Filesystem Hierarchy Stadndard
Synx ファイルシステム階層標準
KN_DIR_RT = /kn/
KN_DIR_HM = ~/kn/
KN_DIR_HID = .kn/
_kn/
– icl/
– pkg/
– log/
– env/
– skl/