すふぃあの記憶

最近、一週間、たいとるの件の現状について、
なんか納得いかなくて色々思ったこと。

まず、ファイルシステムの話から入っていくよ。

・HDDとかの記憶領域に保存されいているファイル＝要素（元）
・要素をある概念（名前）で仕分けしたグループ＝集合
・集合も要素と見ることができる
ここまでは現行のツリー構造のファイルシステムと同じ。
ただ、集合って言うのは、実際には階層的な構造だけを持ってるわけじゃないでしょ。

つまり集合Ａ⊇集合Ｂ∋要素ｘのような関係だけじゃないってこと。
集合Ａ∋要素ｘで、集合Ｂ∋要素ｘという場合でも
集合Ａ⊇集合Ｂでもなければ、集合Ａ⊆集合Ｂでもないっていう状況がある。
現在のファイルシステムはこれが表現できてない。

Javaのパッケージなんかでもそれに従っている（？）せいで、
jp.empressia.http.client.ui.ProjectPanel
jp.empressia.ftp.client.ui.ProjectPanel
というような階層ができでしまう。
別の配置を考えると
jp.empressia.client.ui.http.ProjectPanel
jp.empressia.client.ui.ftp.ProjectPanel
となる。

ひとつのクラスなら気にならなくても、
これが複数になってくるとそうはいかない。
プロトコルが増えたら？uiだけじゃなくてmodelとかは？
clientだけじゃなくてserverは？
こうなると途端にどういう階層が良いのかわからなくなる。
しかし、そもそも「どういう階層が良いのか」ということ自体無意味だとおもう。
だって、プロトコルとドメインとuiとかは、
そもそも入れ子に存在する概念ではないから。
別々の独立した概念だよね。

この場合、
「jp.empressia∩clinet∩ui∩http」であるHttpProjectPanel
と、
「jp.empressia∩clinet∩ui∩ftp」であるFtpProjectPanel
と分ければいい（識別のためにProjectPanelの名前は変えた、別に同じままでも良いと思うけど）。
もちろん「jp.empressia∩clinet∩ui∩ftp」＝「jp.empressia∩ftp∩clinet∩ui」ね、入れ替えても同じ。
ここで、「.」は従来どおりの関係にあるものを表記した（jp⊇empressia）。
「jp.empressia∩clinet∩ui」
こうするとにはHttpProjectPanelとFtpProjectPanelがあることになる。
もしかしたら、両方の基底クラスCommonProjectPanelもあるかもしれない（名前はてけとーです）。
つまり、パッケージとか、ディレクトリとかは実際のニーズとしては、
入れ子だけとは限らないはずなのだ。


もしかしたら、ディレクトリという名前のとおり、
住所という感覚が強すぎるのかもしれない。
例は良くないけど、「アメリカ表記の住所と、日本表記の住所は同じ場所でも別物」みたいなイメージが必要だと思う。
もっかい言うけど、ドメインと機能、表現っていうのは入れ子になるものじゃないんだよね。

もちろん、入れ子があり得ないわけじゃないから部分の制御はきっちり必要だけど。
たとえば、
「jp.empressia∩clinet∩ui∩protocol.http」とか。

さらにいえばHttpProjectModelっていうのがあるのなら
「jp.empressia∩clinet∩model∩protocol.http」とかにあるだろうし
「jp.empressia∩clinet∩protocol.http」をみれば、
HttpProjectModelとHttpProjectPanelがあることになる。
すごい自然だと思わない？
現在のシステムの拡張として実装できるはずだから、まずはそこからかな。

１．HDDとかの記憶領域に保存されいているファイル＝要素
２．要素をある概念（名前）で仕分けしたグループ＝集合
３．集合も要素と見ることができる
４．集合は別の集合と重なり合ってはならず、包含関係になければならない
４を撤廃する。
もしくは、４を「集合は別の集合に重なり合ってもよく、包含関係にあってよい」と書き換える。
それだけ。拡張ですむよね。

実装概念の目安としては、
ファイルに当たる要素と、集合を別のレイヤーとして捕らえるのがいいと思う。
問題は、制限をはずすのだから、処理は重くなり、資源をより必要とする事になるはず。
まぁ、同じグループに全部入れるとか変なことはないと思うけど。
検索のアルゴリズムとかは考えないとかもね。

あと、もしかしたらショートカットとかシンボリックリンクとか要らなくなるかな。
集合同士に優先度とか重みはないし、
ファイルは平坦に配置されてるイメージだから、
階層とかないし。

まぁ、昔は、資源が乏しかったから、そういう制限入れたのかな。
そろそろ新しくしようよ。
Javaとかのプログラムのパッケージも。
XMLとかの名前空間も。
OSのファイルシステムも。

それができたら、ネットでuiとか検索すると世界中のuiがヒットするのかなぁ。
その中から自分のほしいパッケージを探すのとかも楽しそう。
今のJavaって「最初に」ドメインで区切るし。

早く広まって実現するといいな。
JavaなLookingGlassとかに取り込まれないかしら。

以下、メモ

既存のディレクトリという概念から
包含関係制限をなくす。
階層的概念については問う必要はない。


ファイル：
ハードディスクやフロッピーディスク、CD-ROMなどの記憶装置に記録されたデータのまとまり
集合：
任意個数のファイル・集合の集まり

内包的記法＝動的ファイル管理＞条件を示すことで成立？

外延的記法=静的ファイル管理＞マークすることで成立？