100%pure .net OS

100%pure .net OSの夢

アセンブリは名前とバージョン番号を持つ。それらはバージョン番号でソートされた適当なデータ構造のリストに格納され、このリストはさらに名前をキーとするハッシュテーブル(辞書)に格納される。

＃ハッシュテーブルでは全項目のリストアップにハッシュテーブルサイズだけの時間がかかる。でもはっしゅテーブルのサイズは普通アダプティブに増加させていくものだし、この場合アセンブリの個数というのは高速化を考慮しなければいけない程の量にはならないだろうから、現状の.netのDictionary.Keysにforeachするみたいな方法で全ての保持しているアセンブリをリストするなんて事は気軽にできるはずだ。
＃ここでハッシュテーブルというデータ構造を選択しているのはハッシュテーブル特有の種々の高速なO(1)操作が使いたいわけではなく、要するに、フォルダを指定してインストールという意味のないインストール操作を排除できる事が超超超重要なのだ。あれ、本当に意味が分からないよね。

アセンブリからアセンブリへの参照は名前及びバージョンに対して対応状況を判定するデリゲードによって指定される。Enumerable.Lastメソッドみたいな感じで見つかった最新の対応バージョンを参照する。

ユーザも仮想的なオブジェクトとしてアプリケーションのエントリポイントを持つアセンブリへの参照をやはり名前とバージョンの対応状況判定デリゲードで持つ(常に最新バージョンを使うor必要なバージョンのリストを指定する、みたいなGUIによる設定が必要だろう)。

後はガベージコレクションでアンインストールは自動だぜ！！。インストール時にフォルダを指定するなんて一般のユーザにやらせるには低級でレガシーすぎる操作はもう要らないぜ！。ディレクトリツリーベース(あるいはタグベース)のファイルシステムはユーザが作成するドキュメントファイルのためだけに使うぜ！！

技術的問題点は皆無なのが空恐ろしい。しかしこんなのがオーバーヘッドの問題なく実現するのは一体いつの時代なのだろうか。

しかも、これで、ハッシュテーブルをインターネットに置くようにすれば・・・。バージョン管理システムや入依存関係解決付きのパッケージ管理システムがおもちゃのように見えてくる。開発初期段階のアルファバージョンだろうと、技術的な問題のテストとして作ったトイライブラリだろうと、世界中のどこかで誰かがまだそれを必要としている限りはガベージコレクトされずに生き残り、誰も必要としなくなった後にいつのまにかガベージコレクトされてひっそりと消えていくわけだ。

はじめnetびいきで書き始めたけど、こうやって書いてみると、むしろグーグル向きのアイデアだなあ。