アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
デスクトップPC(詰め替え用) (スコア:0)
中身をまるごと取り替えるような作業を、消臭剤の詰め替えくらい簡単にできたら資源が節約できそうです
# OSの詰め替えはどうしよう...
Re:デスクトップPC(詰め替え用) (スコア:1)
>中身をまるごと取り替えるような作業を、消臭剤の詰め替えくらい簡単にできたら資源が節約できそうです
メーカー製でもM-ATXやATXに準拠した電源やケースを使っていたらそれも簡単なんですがね。
Re:デスクトップPC(詰め替え用) (スコア:1)
そっち分野は全く知らないのですが、
もしかして、「準拠」といっても、その準拠すべき規格自体が
毎年のように新しいのが出て、そして古いのが「消えて」いって、
しまってるんだったりしませんか?
あと、交換が(往々にして機械的な意味で)楽かどうか?ってのも有るし。
それこそ消臭剤なみに簡単になってくれないとなあ。
#洗濯漂白剤の樹脂ボトルは、詰め替え(再補充)をし易いように、年々少しづつ形状が改良されてるので、なかなか感心してるG7
基板剥き出しという時点で既にヒイてしまうのが、一般人ってものかなーと。
----
Re:デスクトップPC(詰め替え用) (スコア:0)
Re:デスクトップPC(詰め替え用) (スコア:1)
> 毎年のように新しいのが出て、そして古いのが「消えて」いって、
> しまってるんだったりしませんか?
私も近年の状況には疎いのですが、以前、手元にAT規格のケース/電源ばかり残って、
新しいATXのマザーに交換出来ないという事態がありました。
> Windowsみたいな商用OSは乗換えを敢えて阻害することでビジネスモデルを成り立ち易くする(笑)でしょうから、多くを期待できないです。
んー、ビジネスモデルとしては新バージョンにどんどん乗り換えてもらう方が
儲かるでしょうから、彼らとしても乗換えを容易にしたいんじゃないかと
思いますが…
Windows3.0(遅くとも95)に/homeを用意しなかった先見性の無さが
足を引っ張ってるんだと思います。
> もっと「切り離し」やすさを考慮して設計を一新したようなツールとその置き方を
> 採用したような
BSDをベースにオブジェクト指向を導入して、アプリとデータをもっと
密接に関連付けると言うのは(最近話題の)金子氏がやっていましたが、
切り離すときにはどう考えれば良いのでしょうね?
データの置き場を分離するのは容易として、障害はアプリの設定、それも
複数アプリが関係した設定じゃないかと思います。
(メーラにエディタのpathを設定したとして、再インストール時に別の
エディタを選んだらどうなる?)
Re:デスクトップPC(詰め替え用) (スコア:1)
>儲かるでしょうから、彼らとしても乗換えを容易にしたいんじゃないかと
うーん。乗り換えの定義次第なような気がしています。
たとえばデータをデータ(=それこそが存続させるべき対象)だとも思わないような
まるごと交換してしまっても平気な人なら、それこそ今のままでもいいんでしょうし。
>Windows3.0(遅くとも95)に/homeを用意しなかった先見性の無さが
近年、自分用のWin環境を宛がわれたら、最初にやるのが\homeを作ることだったり(^^;
#\home\G7 は作らないのでG7
>BSDをベースにオブジェクト指向を導入して、アプリとデータをもっと
>密接に関連付けると言うのは(最近話題の)金子氏がやっていましたが、
>切り離すときにはどう考えれば良いのでしょうね?
OOPの「ルーチンとデータを関連付ける」ってのは、
なにも物理的にくっつけてゴタマゼにしてしまうことを
指すわけではないので、まあいいんじゃないでしょうか。
むしろ「切り離されてるという事実を(Objectの中に)隠蔽」してしまえるんで、
好都合かと。まああくまでも旨くやればという前提ですが。
切り離しても、計算機にはポインタ(とか参照とかリンクとかエイリアスとかショートカットとか…)という
強い味方がついてますので、心配には及ばないと思います。
>データの置き場を分離するのは容易として、障害はアプリの設定、それも
>複数アプリが関係した設定じゃないかと思います。
>(メーラにエディタのpathを設定したとして、再インストール時に別の
>エディタを選んだらどうなる?)
まずpath(環境変数のアレのことですよね?)なんていう非OOP的(^^;なものは捨てます。
そういうものはObject「が」知っていればいいんです。
次に、じゃあどのObjectが知っているのか?ですが、
ここで委譲というかChainOfResponsivilityというかDecoratorというか…を
旨く使うのが味噌でしょうね。
つまり、「これってどこに置いたらいいんだべ?」と思ったら、
「とりあえずObjectにしとけば、後で融通が効くべ」という方向に持っていく。
メーラやエディタ等の所謂ツールは、素の実行ファイルそのまんまみたいなObjectのほかに、
それに一皮かぶせたようなObject…というか一皮のためのProxy…を併用するといいと思います。
その皮に、自分用の設定情報とかを混ぜ込んでおけばいいんです。
そうすれば、自分がそのProxyをviだと思って叩いたら、実は素のvi+自分用.exrc をたたいたことになる、
みたいにできます。
#Proxyとは「代理」という意味です。ここではそれ以上の特定の意味(例:Network越え)を
#もたせる意図はありません。そういうのはサブクラスの仕事なので。
Proxyは幾つでも使い分けが可能なはずです。つーか、そうでないとProxyにする意味がない。
#WebブラウザのCookieなどを記憶する「コンテキスト」としても、このProxyは活用できると思います。
閑話休題。素のviはROMでも構わないんですが、Proxy(のうちの幾つか)はRAMってことにしとけば、
そこに「自分が使いたいエディタへの参照」をSlotとして空けておけますよね。
また、エディタ種を深く考慮しないProxyも居ていいでしょうね。
まあなんか知らないけどとにかくエディタに繋がってるらしきProxyを
どっか目立つところ(藁)に置いておけばいいっていう。
忘れてたけど、仕事で扱ってる某システムでは、Toolクラスがあるのでした。
Toolは一般ユーザから見ればROMだし複製も作れないObjectなんだけど、
上記のようにして一般ユーザが弄れるクラスとしてToolProxyを作ることは可能かも知れません。
うん、今度やってみようかな…
なお、このProxyの話は、OOP風にいえばProxyですが、Lisp風にいえばClosureだなーと思います。
#設定を1つづつ追加するのがカリー化って奴、なのかなあ…