{RFC 3092}{高次構文変数}{foo}(3)
{希哲館}{又構文変数}{希哲14年1月15日のツイスト}{希哲14年1月15日}{アルファベット順}{bax}{bay}{baz}{bar}{foo}(11)
{開発}{開発記録}{qux}{fly}{例外仕様別名}{sry}{明示的手抜き}{DORM}{希哲13年7月17日}{let()}(18)

{希哲13年7月17日の開発 K#F85E/5B28-E9C9}

また妙な閃きを得てしまった。

明示的手抜き例外仕様別名

今日も Iti/src/site_/ 以下の整理をしようと思ったところで,拡張子 .u.h にふと目が留まり,let() なども含めたこの種の手法を「明示的手抜き」として概念化出来そうなことに気付いた。

ここで,有用視してきたハリボテのような手抜き函数サボルーチン」も明示的に出来ないか,と考え始めた。

最初,廃止していた cry を復活させてサボルーチンであることを明示することを考えたが,これは dry の対義語として使った方が分かりやすい。その後,印として何らかの込め言を入れることも考えたが,これはこれで煩わしく分かりにくい。スラッシュ三本(///)を末尾に入れて「サンボン」という洒落も考えたが,これはやりすぎだろう。

結局,例外禁止の dry と例外許可の cry のどちらかを例外仕様に記述することを交度規約で推奨し,これが無ければサボルーチンとみなす,という案に落ち着きつつあったが,サボルーチンの明示性に欠け,検索性も悪いという点がどうしても引っかかった。

そこで唐突に閃いたのが,〈sorry〉の意で sry を使うという案だった。C は伝統的にサブルーチンという用語を使わないため,SR がサボルーチンの略にもかかっている。

sry を機能上 cry と同義にしておきつつ,出放りの暫定的明示に使うことで,明示的手抜きの原則に沿わせることが出来る。論組役は,未完成の函数に sry を付け,完成時に cry か dry かを選ぶことで函数が完成していることを明示する。dry は厳格な方なので dry かつ未完成,ということは少ない気がするが,サボルーチンが例外を出すかどうかは大した問題ではないので追い追い都合が良い方に調整していく。

この sry, dry, cry を「例外仕様(fly)別名」という概念でまとめておくことにした。fly も含めて,キーボード上で頭文字が全て連続しているというのも面白い。

廃止を決めてから使い道を模索していた cry の活用場所も見つかり,色々なことが丸くおさまった。

DORM

これまで DG_T を中心に ORM 的な機能を担わせる,ということを考えてきたが,この考え方を「DORM」と呼ぶことにした。以前から思いついていた名前だが,いまいち引っかかりが無く決めかねていた。今日,〈dorm〉とも略されるドミトリー永続化が上手くかかっていることに気付いて採用を決めた。

foobar の拡張

の例示などに使う foo, bar, baz の独自拡張として,bay, bax, baw……などと加えていくことを考えた。qux 以降は見慣れず,不規則過ぎるため。

{foo}(1)
{foo}{UID 1000}{虎哲*ツバメ}{作業用者}{フット化}{作業用者の登録}{〈foot〉}{Linux 用者}{root}{Synx}(10)

{foot K#F85E/4686-59AC}

汎用低権限用者名として希哲11年4月16日考案。〈foot〉は地位が低いことも意味する他,鍵母配列上でちょうど root の r の下になる。

従来までの命名体系見直しのため,u01 の代わりに使用する。虎哲*ツバメに採用予定。

希哲13年6月3日Basic 認証で使う適当な用者名を探していた時,foo に似ていることに気付いた。むしろこれまで気付かなかったのが不思議だ。

{foo}

{}