8/3,4)2010-08-16ネームスペース概論ネームスペースについて、色々調べたので今度は自分の考えをだらだら書く。今思っているのは、ネームスペースを主要な言語の要素として考えたいという事だ。オブジェクトだとか末尾再帰について色々うるさく言う人は沢山いるのに、ネームスペースは日陰者というか、言語開発者が最後に面倒くさそうに付ける物という程度の人気しか無い。モダンなネームスペースが特徴です!とセールスポイントに挙げてる言語に出会った試しが無い。世の中には名前が原因で起こる問題が沢山あるし、本当はネームスペースの問題なのに他の問題と思われている物も沢山あると思う。いう物にはネームスペースが解決の糸口になると思う。ネームスペースがどういう物か、どんな種類があるかを定義したい。プログラミング技術に散在しているネームスペースっぽい問題の共通点を考えたい。ネームスペースが取り上げる対象について考える。パッケージのようなライブラリ管理の仕組みも取り上げる。オブジェクト指向言語のクラスもネームスペースの一種と考える。他にも名前の問題はミクロな場所に潜んでいる。関数内のレキシカルスコープ、ダイナミックスコープも名前の問題だし、継承されたオブジェクトのインスタンス変数も名前が関係している。トランザクションも微妙な所だけどネームスペースの問題と考えると面白いと思う。このような問題の対象については、二つの立場があると思う。ネームスペースは完全に人間による呼び名だけの問題で、プログラムの意味とは関係無いという立場。コンピュータから見るとどのオブジェクトもアドレスでしか無いので、名前が重複しているかどうか、どのように名前を解決するかはプログラムの意味に関係しない。人間だけの問題である。いわゆるネームスペースと呼ばれる物はこの立場だろう。実装の話で言うと、名前はコンパイル時に解決される。一つ、名前は意味であると考える立場もある。この立場では、名前は代数を構成し、同じ名前の物は同じ性質を共有する。ネームスペースと関数の組み合わせで多態を実装出来る。モジュールをパラメータ化出来るそうです。この立場で考えるとオブジェクト指向言語のクラスや、階層化トランザクションもネームスペースの枠内で考える事が出来る。このような名前は普通実行時に解決される。例に取ると分かりやすい。名前を管理するモジュールはプログラムの意味に全く影響を及ぼさない。関数の同じ性質を現す多態は型クラスを使う。この型クラスをネームスペースに含めるかどうかはとても面白い議論だ。つぎに、どんな種類があるのか構造的特徴から考える。これはオブジェクト指向の言葉を借りて、ざっくり単一継承か多継承で考えると分かりやすい。単一継承というのは、スコープが一つの根から枝分かれした木状になっている物を言う。スコープの末端で解決されないシンボルは、書くスコープでただ一つだけある根っこのスコープで解決される。レキスカルスコープは文の形に沿った単一継承ネームスペースだし、ダイナミックスコープも実行経路にそって木を形作っている。単一継承の場合、木の末端と根で同じ名前が定義されていれば、単に末端の物が優先される。多継承というのは、スコープの根が沢山あるやつを言う。パッケージでは複数のパッケージから名前をインポートする事が出来る。名前の衝突が起きたら、色々クリエイティブな方法で解決する。次に、ネームスペースは意味に関係すると考えると、特に単一継承のデザインで二つの異なる方法がる。一つは、子スコープが親スコープを継承した時、親スコープの意味は全く変わらないとする静的な方法。一つは子スコープによって親スコープが拡張され、親スコープから子スコープの内容を参照出来るとする動的な方法だ。一般的なネームスペースやレキシカルスコープでは静的な方法が使われる。一方でオブジェクト指向言語や型クラスは動的な方法が使われる。階層トランザクションも、単一継承で静的なネームスペース問題と考える事が出来る。この場合、ある親トランザクション内の子トランザクションが二つのプロセスで同時に実行されている時、二つのトランザクションは単一の親トランザクションを参照している。いうわけで、スコープ、オブジェクト、多態、トランザクションにまつわる性質は、ネームスーペースの問題を別の角度で見たものだという気がして来た。疲れたので今日はここまで。「からくり計算器」ご報告カラクリ計算器とは何か?月別アーカイブはてなブログをはじめよう!propellaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。