パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

OOLとは何か、OOPとは何か」記事へのコメント

  • DQNはともかく少なくとも俺は、
    「OO言語を使うの必須だ」とは言ってません。
    #俺もまたDQNかどうかは、さておくとして。

    べつにLispでもいいんじゃないですか?
    OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
    (気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
    それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。

    問題はshだとそれ「すら」旨くできない、という点だと思います。
    OO「も」出来ない(やりにくい)。
    そしてそれは、それ以外の色々なことも出来ない(やりに
    • 議論の基礎知識がないので本格参入はできませんが、ちゃちゃだけでも^^;;

      まず、ご存じないような感じがするのでirbの紹介
      http://www.rubyist.net/~matz/?date=20030815
      これを使ってUnixのコマンドを呼べばかなりのことができそうに感じます。

      Windowsでしたら、ActiveScriptRubyをいれれば、一通り遊べます。
      http://www.geocities.co.jp/SiliconValley-PaloAlto/9251/ruby/

      もっとも、Rubyからでは標準出力と標準エラー出力を同時に取れなかったと思うため、
      完璧なものではないでしょうけれども。

      ###
      個人的に「UnixのOOラッパーとしてのRuby」という言い回しに惹かれました。
      言い換えれば、そんなRubyが真に動く環境ではUnixと同じことができるわけですね?
      しかもOOラッピングされた状態で。

      そうなったら、もはやRubyが何の上で動いているかは関係ないのかもしれません。
      #2次会でも口走った気がするのですが、.NET特にWinFXがこれだ、
      #とわたしは思っているのです
      親コメント
      • by G7 (3009) on 2004年06月06日 14時18分 (#564256)
        >議論の基礎知識がないので本格参入はできませんが、ちゃちゃだけでも^^;;

        や、俺もよく判っていません。
        このmishimaさんの数年来のm(__)m日記を手繰って読んでるだけです。
        #そういや、日記へのコメントのページから、作者の記事一覧ページへ、行けるリンクが無いような…>スラド

        >まず、ご存じないような感じがするのでirbの紹介
        >Windowsでしたら、ActiveScriptRubyをいれれば、一通り遊べます。

        あう。名前は知っていますが使ったことが無いもんで言及しませんでした。

        そういやLispつーかSchemeな人々が時折言ってますね、
        「いっそLispをコマンドラインにしたらどうよ?」と。
        #「やっぱり括弧がウザイかな?」とか(^^;

        >もっとも、Rubyからでは標準出力と標準エラー出力を同時に取れなかったと思うため、
        >完璧なものではないでしょうけれども。

        まあ、1つのプロセスから互いにバラバラに出される2つの出力を、
        また1つのプロセスで受けるのは、
        (スレッドもselectも使わなければ)根本的に厄介な問題なので…
        #以前知人が、そういうことをJavaでやろうとして、悶絶していたっけ…

        てゆーか、そういう厄介が有るあたりに、
        Pipe方式の部品化の未来の無さを感じてしまってます俺は。

        部品化のことを考えたら、やっぱり、
        実行主体(スレッドっていうか)は、オブジェクト(データ塊)とは、
        へたに一対一対応に限定してしまわないほうが、よいんじゃないかと。

        だいたい、Unixの(少なくとも現状の)シェルで楽にやれるリダイレクトだのパイプだのの範囲だと、
        起動時に接続を決定せざるを得ず、後から切り替えることすら出来ない。
        こんなもんが「部品化」と呼べるのか?ってのは、かなり疑問です。

        UnixのあのPipeは、無数(?)にあるアーキテクチャパターンから見れば、
        そのうちのほんの1つであるPipelineパターンをサポートしてるだけです。
        しかも上記のようにHot切り替えも出来ない。駄目駄目です。

        まあ、着脱できないものを無理矢理着脱可能にすることはそれなりに出来ます。
        たとえばWindowシステムとOOPラッパーとの間でも、
        Native Widgetより寿命が「長い」ラッパーを作ることで、
        Native Widgetがサポートしてない変更を
        (つまりNative Widgetを一旦捨てて作り直すことで)
        変更可能に仕立ててしまう、なんてなことが出来ます。

        でもまあそれは所謂「回避技術」であって、あまり前向きというかスッキリ感というかは乏しいなと。

        >そうなったら、もはやRubyが何の上で動いているかは関係ないのかもしれません。

        いや、「何を」ラップするのか?という問題が残ります。

        たとえばUnixのselect「を」ラップしましたとか言われたら、他のOSはどうするのよ?とか。
        頑張ればエミュレートは出来るかも知れないが効率悪そうだなとか。

        #GUIアプリの「fork」が見てみたいのでG7
        #やっぱり、同じ窓構成を持ったプロセス2つに「分身」するんでしょか?(藁
        #便利なような、混乱のもとでしかないような?
        ##ついでに「exec」したらどうなるんだろ?
        ##窓の中身が「ぱっ」と別アプリに描き替わるの?(藁
        ###そういやリナザウだかで、C++ベースのアプリの起動の遅さをカバーするために、
        ###「途中まで起動」した状態のプロセスを眠らせといて、そいつをアプリ起動の要求に応じてforkする、
        ###っていう技術を使ってるとか聞いた気がしますが…
        親コメント
        • > だいたい、Unixの(少なくとも現状の)シェルで楽にやれるリダイレクトだのパイプだのの範囲だと、
          > 起動時に接続を決定せざるを得ず、後から切り替えることすら出来ない。
          > こんなもんが「部品化」と呼べるのか?ってのは、かなり疑問です。

          同意。
          一番必要なのはその部分だと思ってます。
          ま、着脱用の処理をするプロセスを一個はさんで
          無理矢理着脱可能にしちゃえばいいと思ってるのですが。
          (統一的にそういうものを扱うツールというのがいままで Unix に
          なかったのが不思議)

          > #GUIアプリの「fork」が見てみたいのでG7
          > #やっぱり、同じ窓構成を持ったプロセス2つに「分身」するんでしょか?(藁
          > #便利なような、混乱のもとでしかないような?

          いわゆる GUI アプリって、変な構造ですよね。
          「いまどんな画面を表示しているか?」ということが重要なのに、
          その「状態」がメモリ上にしかなくて保存することが難しい。
          そのくせバグが多くてよく落ちる。そうすると最初からやり直し。

          GUI アプリであっても、Web アプリであれば状態は DB サーバに
          格納できたりして被害はぐんと小さくなる。
          これだと fork の意味がはっきりしてくるように思うわけですが。
          (ブラウザのウィンドウの複製か、DB のデータの複製か)
          --
          # mishimaは本田透先生を熱烈に応援しています
          親コメント
          • by G7 (3009) on 2004年06月11日 22時11分 (#568052)
            >ま、着脱用の処理をするプロセスを一個はさんで
            >無理矢理着脱可能にしちゃえばいいと思ってるのですが。

            Unixのプロセスの管理形態とパイプとの関連性って、どうなってるんでしたっけ。
            すみません、いまだによく判ってなくて。
            つまり、親子関係だったかな?という話です。

            Unixのプロセスって親子関係の縛りがキツイですよね。
            親子関係自体を自由自在に乗り換えれるといいんでしょうけど、なんかそうじゃないようで。

            つまり着脱をOSのアーキテクチャが許してくれるかな?という話です。どうでしたっけ?

            OOPの場合は、基本的に親子関係なんてものはアテにしない、
            ネットワーク(通信という意味じゃなく多対多という意味の)モデルです。
            だからどうとでも繋がり得る。

            C言語で喩える(藁)と、Auto変数とmallocの違い。
            結局、生成順序で縛ると、プログラムモデルの自由度が落ちる、というのが
            OOP(というよりLisp)の慧眼なのでしょう。
            そしてその際、廃棄モデルを、順序依存廃棄じゃなく参照切れ廃棄モデル(つまりGC)にする必要を見抜いた。

            いっぽうUnixは、やっぱり、生成順序モデルの落とし子なんだと思います。
            それで表現可能な範囲の仕事はエレガントにこなすけど、それ以上は困難だという。

            #よく知らないんですが、たしかNamedPipeってのを使えば、この問題はかなりエレガントに解消できるんでしたよね。
            #Pipeを着脱可能なパッチケーブルみたいに使えるっつー。
            #…でもNamedなので名前空間(FileSystem)中の名前を消費するんでしたよね。
            #これだと大量に使いたいときや動的に割り当てたいとき、名前の衝突を管理するという手間が増えて困る。
            #つまりNamedPipe風だが無名なPipeを(しかももちろん一般ユーザ権限で)作るのが楽でないと困る。
            #そして、もしそれを作っても、今度は無名のソレを誰がいつ解放責任を取るか?っていう問題が発生する。
            #親プロセスが責任取るのか?でもそれじゃ結局親子問題が再燃だ。うーんうーん…
            ##つまり、「名前(ファイル名)とプロセスのどちらかを使ってしかPipeを束縛することが出来ない」のが問題なんだと思います。
            ##そしてこれは、PiepのみならずUnixのあらゆる面を支配してます。なにせUnixにはFileとProcessしか無い。

            >いわゆる GUI アプリって、変な構造ですよね。
            >「いまどんな画面を表示しているか?」ということが重要なのに、
            >その「状態」がメモリ上にしかなくて保存することが難しい。
            >そのくせバグが多くてよく落ちる。そうすると最初からやり直し。

            保存については、Squeakみたいに記憶の一元化をするという手も有りますし、
            BeOS(噂の又聞きですがたしか)みたいにアプリの状態保存をOS(とAPI)のネイティブな機能として盛り込む、という手もあります。

            #ややこしいNetwork構造をFileとかに保存するアルゴリズムについては、
            #JavaなりRubyなりでも最初からライブラリとして実装済みなので、心配無用。

            てか、vi(m)だって-rがあるじゃないですか。
            同じことをGUIアプリがやることは(原理的には)なんぼでも可能です。本質じゃない。

            問題は、アプリ設計者(?)が、「何が状態なのか」をどう考えるか、って点だけです。つまり設計ね。
            カーソル位置を保存するエディタと、しないエディタがある。その程度の差異です。

            あと落ちるってのは今やデマでしょう。Winアプリも「OSが」9xまでは落ちましたが、
            NT系だと vi(Unixの)が落ちるのと大差無い確率ですね。
            リソース(Windows用語じゃなくメモリ含めた広い意味で)の管理が確かならば、
            そうそう落ちないようですよ。
            原理的に落ちやすいって訳ではなく足回りが腐ってるかどうかに依存するんだと思います。
            まあイベント処理とかでデッドロックする恐れは有りますが(^^;

            >GUI アプリであっても、Web アプリであれば状態は DB サーバに
            >格納できたりして被害はぐんと小さくなる。

            一昔前に業務アプリとして隆盛だったC/S方式でも、それは同じですね。
            逆にいえばWebアプリ(の自分のセッションの鯖側)「が」落ちる(壊れる)恐れだって
            ないわけじゃないんですし。
            #特に今はアプリ作者の腕次第って場合も多い黎明期なんで、セッション壊しも有り得ない話じゃない。
            親コメント
            • あー、感覚的な話ですけど、
              G7 さんは SysV 系統のアプローチなんですな。
              俺は BSD なアプローチの方が好みです。あくまで感覚的ですが。

              結局のところ、プログラム開発ってのは複雑性の管理に他ならんわけです。
              で、その複雑性を誰が面倒を見るか、という部分で
              安定性=障害耐性や保守性、可用性、移植性、性能、開発効率
              なんかが変わってくると。
              Unix は「複雑なもの(=ファイル構造のネットワーク化とか)は
              面倒見切れん、必要ならあとはユーザ空間で工夫してやれ」と
              切り捨てたところがプロダクトとして最も良い部分でしょう。
              そんな Unix も多少の拡張はあるわけですが、
              利用者(=アプリ開発者)にとっての機能重視で拡張する
              アプローチはどちらかといえば SysV 風、シンプルに実装側に
              とって分かりやすい形で拡張するアプローチが BSD 風だと
              (勝手に)思ってます。

              > Unixのプロセスの管理形態とパイプとの関連性って、どうなってるんでしたっけ。
              > つまり、親子関係だったかな?という話です。

              そですね。名前つきパイプでない限りはそうなります。
              名前つきパイプについてはその後 G7 さんが書かれたとおり。

              > つまり着脱をOSのアーキテクチャが許してくれるかな?という話です。どうでしたっけ?

              基本的には OS は許してくれません。必要ならユーザ空間で工夫してやれ、と。
              そしてそれはそんなに難しい話ではないでしょう。

              > #これだと大量に使いたいときや動的に割り当てたいとき、名前の衝突を管理するという手間が増えて困る。
              > #つまりNamedPipe風だが無名なPipeを(しかももちろん一般ユーザ権限で)作るのが楽でないと困る。

              まぁ現実的には「アプリケーション側にはパイプに見える
              ストリームだけど、実は TCP or UNIX ソケットの接続でした」
              とかいうアプローチで十分だと思いますよ。
              自分の書いた「プロセスを一個はさめば着脱可能」ってのも
              その方法で実装してます。

              もし本物のパイプでやるとしても、BSD 的アプローチなら例えば
              「プロセス ID ごとのディレクトリを作って、その中に作ればいいんだよ~!」
              「名前がかぶったら .1, .2, .3, ... みたいな拡張子をつければいいんだよ~!」
              とか答えるところ。

              > #そして、もしそれを作っても、今度は無名のソレを誰がいつ解放責任を取るか?っていう問題が発生する。
              > #親プロセスが責任取るのか?でもそれじゃ結局親子問題が再燃だ。うーんうーん…

              これも、BSD 的アプローチなら
              「cron で定期的に使われてなさげなパイプを削除するプログラムを動かせばいいんだよ~!」
              とか答えるところです。

              > 問題は、アプリ設計者(?)が、「何が状態なのか」をどう考えるか、って点だけです。つまり設計ね。
              > カーソル位置を保存するエディタと、しないエディタがある。その程度の差異です。

              ここで開発者側と利用者側の視点の差が出てしまうところが
              (GUI に限らず) UI のもってる問題じゃないかなぁ。
              開発者「テキストエディタの『状態』はファイルだろう」
              利用者「どのファイルを編集しているか、だって重要な『状態』だよ!」
              みたいな。

              うーん、基本的に俺が考えているのが「小規模」「バグあり」
              「ユーザサイド」なアプリを対象に、
              「エンドユーザがプログラムの修正を簡単に行うためには」
              「ゼロからの実装を簡単にするには」
              「再設計無しに(または変更を最小限に)大規模まで拡張するには」
              みたいなことだというのが自覚できたような気がします。
              --
              # mishimaは本田透先生を熱烈に応援しています
              親コメント
              • by G7 (3009) on 2004年06月17日 10時53分 (#571326)
                >利用者(=アプリ開発者)にとっての機能重視で拡張する

                いや、別に俺は「拡張」したいわけではありません。
                必要な機能は欲しいし、不要ならば要りません。それだけ。
                それがUnixと重なってる部分が有るか無いかってのは
                俺としては関心事から比較的遠いです。

                例えばProcess壁とかは要らないと思ってますし。
                理由は前述のとおり。Process間通信の"必要"性は、Object間通信のコストを増やすだけだから(^^;

                余談ですが
                バッファオーバーフロー攻撃などの昨今の頻出を見れば、
                Process間にさえ壁を作ればいいというUnix風の「セキュリティ」モデルは、
                野暮ったいんだろうと思います。
                もっと小さい単位…たとえばStringとかArrayとか…の不正使用を抑止するほうが
                余程大事なんじゃないかと。
                よーするに鯖プログラムを全部Java(笑)とかに置き換えたらどうよ?と。

                #もちろんCベースでもそれらを実現する手段が幾つか有るようなんですが、
                #どうせCではそれ以外にも苦労が多いんで、どっかでまとめてリプレースしたいなあと。
                #ExceptionとGCのない言語環境で「アプリ」を作るなんて、もう嫌です(T_T)

                あと、C主義の限界ってのもありますね。 C主義ってのは、
                (記憶が正しければK&R2の冒頭の宣言ですが)プログラマは何をするかを自分自身で判ってる、という前提
                です。
                一見正当な主張に聞こえますが、
                OOPの多態とか、Callbackとか、Closureとか、GCとか、といったもの(の恩恵)を考えると、
                なんでもプログラマ本人に責任取らせようとすると、却って「プログラムモデルが」煩雑になる、
                という側面があるように感じています。
                if文の洪水を自分で管理するより、Objectに管理させたほうが良い、とか。
                メモリ解放の複雑怪奇な手順(複雑なデータ構造では複雑な解放が必要ですよね)を機械任せにする、とか。

                以上のことはOSじゃなくライブラリが出来る仕事かも知れません。
                ですが、Process壁みたいに、「邪魔」なものもカーネルには有るわけで、
                それを外すところまで視野に入れたいです。

                Unixも、べつに必ずしもシンプルってわけじゃないと思います。
                壁作ったり、色々大変でしょう。
                むしろUnixユーザのほうが、Unixの各種機能を最早空気のように意識してない(ので「シンプル」だと感じる)
                というだけのことだったりしませんかね…

                >基本的には OS は許してくれません。必要ならユーザ空間で工夫してやれ、と。
                >そしてそれはそんなに難しい話ではないでしょう。

                どんな工夫が要るかをちょっと考えたんですが、概念的には結構すごい換骨奪胎だったりしませんかね?

                親子関係を無くすためのラッパーは結局、
                「shell配下の全てのProcessはshell直下の子にする」
                ことになるんじゃないかと思います。
                そして、子Processのstdin/outをPipe(のようなもの)に接続しちゃう。
                これで、shellは必要(?)に応じてPipe同士のつながり関係を替えちゃうことが出来るようになる。

                で、問題は、shellがやらないとならない仕事が結構凄くなっちゃうんじゃないか?という点でして。
                まずマルチスレッドでないとならないでしょうし
                (それともselect()で足りるだろうか?…待てよ、selectって後から待ち受け数を増減できないですよね??)、
                接続関係の変更の要求を子Processから(当然shellへ)投げるための手段も考えてあげないとならない。
                あ。新たなProcessの生成の手段も違ってきますね。"自分の"子(つまりshellの孫)を作っては
                イケナイんだから。まあそういうのはLocalProcessとでも呼べば良いのかも知れませんが。

                あと、出力のmergeとかみたいに、もうちょっと気の利いた世界を目指すなら、どうすりゃいいか
                っていう問題もあります。
                Unixの出力データフォーマットは「構造化」されてないので、
                mergeといっても単純にbyte(または行)単位で混ぜる羽目になる。
                で、単純に混ぜちゃったら意味不明データにしかならないから、無価値。
                無論、混ぜたものを後から分けるのも無理。
                混ぜるっていうか、複数の流れを「同期」したいときが有ると思うんですが、
                同期のための手段がアプリ依存では価値が低い。全アプリ共通であって欲しい。
                でも今のままだとお手上げ。

                #往年のMacのMidiManagerってのが参考になりそう。
                #Midiアプリ同士をそれこそPipeで繋ぎまくれる。稼動中も切り替えできる。
                #なんとご丁寧に、MIDI信号入出力だけじゃなく、同期のために同期信号入出力ってのも有り、これも繋ぎまくれる。
                #ちなみにMacなのでGUIでサクサク切り替え可能。
                #翻って、現状のUnixアプリには同期信号入出力は無いしなあ(^^;
                #改行とかを検知して同期信号をでっち上げるラ
                親コメント
        • ちょっと考え直してきました(謎

          > いや、「何を」ラップするのか?という問題が残ります。
          ここでラップするのはある目的を達成するための手段であって、例えばUnixのselectをラップするのとは違うかと。
          ラッパーは当然selectに相当する処理は提供しますが、select自体は提供しない。
          .NETからWin32APIを呼び出すようなものですから。

          > GUIアプリの「fork」が見てみたいのでG7
          IEの「新しいウィンドウで開く」とかはforkっぽいですかね。

          > ついでに「exec」したらどうなるんだろ?
          こちらはExplorerにURLいれたり、IEにファイルパスいれたり、でしょうか。

          > そういやリナザウだかで、C++ベースのアプリの起動の遅さをカバーするために、
          > 「途中まで起動」した状態のプロセスを眠らせといて、そいつをアプリ起動の要求に応じてforkする、
          > っていう技術を使ってるとか聞いた気がしますが…
          りなざうは持っていたり。。
          確かにpsすると「高速起動」にしたアプリのプロセスが眠っているんですよね。
          それをforkしていたんですか。
          親コメント
          • >ここでラップするのはある目的を達成するための手段であって、例えばUnixのselectをラップするのとは違うかと。

            いや、例えばselectのような「考え方」をラップする、ってことは有ると思います。

            例えば数年前のVersionまでのJava(あれもOSですよね?>Sun(藁))には
            selectそのものどころか、select「的なもの」が何もなかったわけで。
            #Threadを使えば、一応同じようなことは(非効率に)行なうことは出来るけど、そりゃ何か違うわけで。

            APIって、大袈裟にいえばFrameworkなんです。
            使い方のベストプラクティスから、時としてプログラム全体の考え方までをも、「縛る」ものです。
            そう。考え方。

            で、環境なりなんなりに、その「考え方」が最初から無い、ということはよく有るわけです。
            #そういやMSX DOS1にはDirectoryが無かったなあ…(とおい目

            >IEの「新しいウィンドウで開く」とかはforkっぽいですかね。
            >こちらはExplorerにURLいれたり、IEにファイルパスいれたり、でしょうか。

            あはは。あえて言えば似てますね。
            そういう意味では、URL(色んな種類のメディアだのなんだのを飲み込んじゃえる)とか
            それのレンダリングソフト(のPlatform)の実装としてのIE(とWindows)は、興味深いです。

            でも逆にいえば、ああいう処でくらいしか見たことが無いんですよね。
            他のアプリで、あんな挙動をする奴って、見たことが無い。
            作れば当然出来るはずなんだけど。面白そうなんだけど。

            >確かにpsすると「高速起動」にしたアプリのプロセスが眠っているんですよね。
            >それをforkしていたんですか。

            たしか、C++の仮想関数テーブルの解決を「実行ファイルが起動するたびに」やると、
            その手間が馬鹿にならんので…という話だったとうろ覚えしてます。

            確かに素晴らしい話なんですが、逆に言えば、
            ここでもプロセスの壁とOOPとの相性の悪さが見え隠れしてるように思います。
            この問題はたまたまforkで回避できたわけですが、ね…
            親コメント
            • > いや、例えばselectのような「考え方」をラップする、ってことは有ると思います。
              「考え方」は「手段」のこと・・・ではないか、な。
              ちょっとそこまで詰めきれてません、が、
              UNIXselectの一挙手一投足をエミュレートするわけではない、ってことですかね。
              Cygwinとは違う、と。

              > APIって、大袈裟にいえばFrameworkなんです。
              ですよね、ある種「言語」や「ライブラリ」と同種のものと捉えてます。
              で、パラダイム自体がないというのは確かによくありますね。。。
              ありがちなのが無名関数。

              > 他のアプリで、あんな挙動をする奴って、見たことが無い。
              使っている途中で、分身したり変身するソフト・・・他にないですねぇ。
              デスクトップマスコットとかAgentとか呼ばれるソフトと組み合わせたら、
              なにかおもしろいものができないかなぁ・・・。

              > たしか、C++の仮想関数テーブルの解決を「実行ファイルが起動するたびに」やると、
              > その手間が馬鹿にならんので…という話だったとうろ覚えしてます。
              どうも、バッドノウハウの香りがしますね、、
              プロセスの壁、が解決すればこれは大丈夫、と?

              プロセスの壁って、その高さをメソッドの高さにまで下げればそれでいいのでしょうか。
              #いや、メソッドじゃなくてインスタンスか・・・?

              HTMLのフレームページで、上フレームのJavaScriptが、
              下フレームのJavaScriptの変数にアクセスする感じですよね?
              親コメント
              • by G7 (3009) on 2004年06月27日 12時13分 (#577675)
                >> いや、例えばselectのような「考え方」をラップする、ってことは有ると思います。
                >「考え方」は「手段」のこと・・・ではないか、な。

                考え方はWhatあたりだし、手段はHowだろう、と思います。

                >> たしか、C++の仮想関数テーブルの解決を「実行ファイルが起動するたびに」やると、
                >> その手間が馬鹿にならんので…という話だったとうろ覚えしてます。
                >どうも、バッドノウハウの香りがしますね、、

                ある意味でそうかも。

                >プロセスの壁、が解決すればこれは大丈夫、と?
                >
                >プロセスの壁って、その高さをメソッドの高さにまで下げればそれでいいのでしょうか。
                >#いや、メソッドじゃなくてインスタンスか・・・?

                高さとかいうよりも、「どういう事象を」壁で遮るか?という問題だと思います。

                まず、最悪暴走してもプロセスの外を侵さないってのは、
                ポインタが抽象化されていれば(つまりポインタの演算なんてことの権利をアプリ(?)に与えなければ)
                生じようが無くなる問題なので。
                これは一連のモダン(?)なメモリ管理によって万事解決のはず。
                似たような話として、バッファオーバーフロー云々もこれで解決かと。

                あとはリソースのLimitの問題ですね。
                「このプロセスには」メモリは幾つまで、ファイルは幾つまで、を許すとかいうアレ。
                これ、素朴なOOPではサポートしていませんが、
                Javaとかの中でもそういうLimitっぽい制約をかけるっていう研究は
                なされてるみたいなんで、近い将来に期待ってとこかと。

                あと、そもそもUnixスタイルだと、メモリの座(^^;としてはプロセスしか無い
                ってのも、根本的に間違っているわけです。
                実行ファイル(や動的ライブラリ)をメモリにロードしてから、ポインタを「解決」しておいた状態のモノが
                必ずプロセスの中にしか置けないので、今みたいな変な話になる。
                それはそれで別の身分を与えて、他のプログラム(?)から軽量な参照を許すようにすれば、いいわけで。
                なお、いわゆる共有メモリでソレが出来るかどうかは存じません。
                あとハードウェアによる”プロセス単位”のメモリ保護は、この場合は足枷でしかないってことで以下略。

                >HTMLのフレームページで、上フレームのJavaScriptが、
                >下フレームのJavaScriptの変数にアクセスする感じですよね?

                アクセスPATHが有るかどうか、という話も関係してきますね。
                PATHが有ればそれを不正に使う(故意かバグかはさておき)可能性も有るけど、
                じゃあどこまで遮断しようか?と。

                JavaServletのAPIでも、どっかの時点で、
                "セッション"間のアクセスPATHを封じるようなAPI仕様変更が入ってた
                と記憶してます。

                結局プロセスの壁って、全て(?)のPATHが封鎖されちゃってるんですよね。だから困る。
                必要な所だけ開けるってことをしとくと、だいぶ楽になるはず。

                あと、権限を与える単位って、やっぱりスレッドか、それをまとめたもの(スレッドグループっていうのかなあ)
                あたりになるのかも。
                親コメント
      • 基礎知識とか必要ないですよ(笑)

        > 言い換えれば、そんなRubyが真に動く環境ではUnixと同じことができるわけですね?
        > しかもOOラッピングされた状態で。

        ruby とかまともに使ったことがないのでわからんですが、
        もしそういう環境があったとして、どういうところがうれしいですか?
        (傍から聞いていると、単に ruby という製品に囲い込まれているだけのような気がする)
        --
        # mishimaは本田透先生を熱烈に応援しています
        親コメント
        • by G7 (3009) on 2004年06月11日 22時30分 (#568061)
          >(傍から聞いていると、単に ruby という製品に囲い込まれているだけのような気がする)

          それ言ったらお終いです。
          なぜなら、現状のUnixだって「BSD(だっけ)に囲い込まれてる」「Cに囲い込まれてる」
          と言えてしまうんだから。

          >もしそういう環境があったとして、どういうところがうれしいですか?

          OOPで考えられるところ、でしょうね。
          べつに難しくはないですよ。
          今までだって手続き指向という、1つの恣意的な(^^;考え方で考えてただけなんですから、
          それがOOPという別の恣意的な(^^;考え方に移行したって、基本的には同じ。
          あとはどれだけやりたいことが楽にやれるかの違い。
          で、OOPは(支援体制のしっかりした環境/言語なら)快適だと。

          なお、Ruby独特のクサさについては、あまり心配しなくていいと思います。
          おおむね優等生な言語なので、癖で悩むってことはあまり無いです。
          #文法の細かいところで「ん?」と思うこととかは有るけど。

          ----
          ところで、
          http://seasarproject.g.hatena.ne.jp/habuakihiro/20040610#1086855240
          (とその前後周辺の記事)が、ちょっと気になってます。
          特に
          http://seasarproject.g.hatena.ne.jp/habuakihiro/20040610#1086875509
          あたりかな。
          「(状態が)OSのレベルでサポートされているので、ユーザプログラムのレベルではさほど意識する必要はなかったのです。」
          という。

          同意できるような、同意したくないような(^^;

          なにせ上記って、考えようによっては、それこそ「Pipe世界があればOOP要らないっしょ」と
          すごく似た話です。

          ある意味で正論だし、「それじゃ戦えないから状態やねんOOPやねん」とも思うし、
          それでも判らんDQN(笑)はやっぱり居るから救済しろってのもあるだろうし、
          DQNなんか支援しても意味ないじゃんとも思うし…
          うーんうーん。
          親コメント
          • > >(傍から聞いていると、単に ruby という製品に囲い込まれているだけのような気がする)
            > それ言ったらお終いです。
            > なぜなら、現状のUnixだって「BSD(だっけ)に囲い込まれてる」「Cに囲い込まれてる」
            > と言えてしまうんだから。

            それは別の話でしょう。
            「BSD に囲い込まれてしまった」「C に囲い込まれてしまった」。
            それらは過去形です。でも、ruby にはまだ囲い込まれたわけではない。
            ruby は筋がいいのかもしれないけれど、
            それ以外にもスクリプト言語にもいろいろあるわけで、
            それぞれの言語で囲い込みが起きてしまうのはあんまりうれしくない。
            まぁある程度の「選択と集中」ってのは必要なのかも知れんですが。

            > なお、Ruby独特のクサさについては、あまり心配しなくていいと思います。
            > おおむね優等生な言語なので、癖で悩むってことはあまり無いです。

            G7 さんにそう言わせるということはいい言語なんだろうなぁ…

            > ところで、
            > http://seasarproject.g.hatena.ne.jp/habuakihiro/20040610#1086855240
            > (とその前後周辺の記事)が、ちょっと気になってます。

            あ、これ面白いですね。
            なるほど、自分はユーザアプリから Web に来た方なんだけど、
            いわゆる汎用機とかから業務アプリで来た人からすると
            現状の Web ってそういう風に見えるわけか。
            その時代のアプリケーションの流れ、開発の流れ、設計の流れを
            そのまんま Web に落とし込んでるような案件はそこらじゅうにありますね。
            あーいろいろ分かった気がします。

            んー、ただ、はぶ氏の解決したい問題領域と俺の解決したい
            問題領域は、規模が違いますね。
            俺がパイプで何とかなる、と想定しているのは割と小規模だなぁ。
            個人~数人の規模。

            > ある意味で正論だし、「それじゃ戦えないから状態やねんOOPやねん」とも思うし、
            > それでも判らんDQN(笑)はやっぱり居るから救済しろってのもあるだろうし、
            > DQNなんか支援しても意味ないじゃんとも思うし…

            (笑)でも結局、支援しないとどうにもならんとも思うのです。

            ところで、プログラム開発はたいてい小規模→大規模と
            変化していくものだと思いますが、この途中で再設計しろ、
            作り直せ、っていうのがまぁ理想的なんでしょう。
            再設計の途中で上流の設計に変更が生じていろいろ作り直し、
            なんていうのがよくあるパターンだと思いますが、
            例えばその上流部分に宣言型言語を使うことによって
            変更点をそれなりにうまく吸収、なんていう可能性はないもの
            ですかね?
            まぁ思いつきなんですが。
            --
            # mishimaは本田透先生を熱烈に応援しています
            親コメント
            • >それらは過去形です。でも、ruby にはまだ囲い込まれたわけではない。

              それは身も蓋も無さすぎです(^^;

              >それぞれの言語で囲い込みが起きてしまうのはあんまりうれしくない。

              ああ。rubyという実装自体に囲われるのは困りますね。
              #でもそしたらCに囲い込まれてるのも問題視しなきゃだ。

              まあ字面としてのrubyには、流石に囲い込まれる価値はないでしょう。

              #そういう意味では、Unixも、Cというよりは正確にはアセンブラに囲い込まれてるんだよね(藁
              #なんせ*.oとかの中間ファイルはCじゃなくアセンブラとかのためのものでしょ。
              #お陰でCで使うときは*.hなんていう余計な介助物が必要になっちゃう(T_T)

              ただ、JavaやSmalltalkや次世代Perlがやっている、
              VMだかなんだかの上で生きてくっていう路線なら、
              いいんじゃないでしょうか。
              たとえばJVMの上で動く言語は無数に存在するわけで、ああいう感じね。
              尤も、そういうニーズには、Rubyはまだ対処できませんが…。#それともJRubyとか?(^^;

              で、それによって何が替わるかってーと、
              C(アセンブラ)+プロセス+ファイル
              というUnix世界からの脱却ですね。 Java(OS)やSqueakみたいな感じになる。

              >俺がパイプで何とかなる、と想定しているのは割と小規模だなぁ。

              面白いですね。
              俺に言わせれば、Pipeじゃ困るようになると想定してるのは、「更に」小さい領域です。

              つまり、俺とmishimaさんの言葉の両方が正しいとすれば、
              Pipeが生きていける分野は、中(?)規模だ、ということなりそう。

              ただ、規模とは直交じゃないか?という気もしますけどね。
              バッチ処理はPipeと相性良いから、色々な規模で活動できるんじゃないかなとか。

              >(笑)でも結局、支援しないとどうにもならんとも思うのです。

              そーなんですかねえ?(藁

              DQNと立派な開発者との間の能力差は、10倍とも100倍とも、
              或いは更に符号すら違う(藁)という話が有るんで、
              ついてこれねー奴は「ふるい落とす」ほうが正解
              であるような気もしています。

              てゆーか、輪切りが不可能であるような気がしています。
              「能力に応じた仕事」なんてものは実は無いと思っています。
              プログラミングを成り立たせる必要能力水準は、そんなに低くないんで、
              結局一握りの人以外は「どんな仕事でも」役立たない、というだけじゃないかと。

              #明らかに能力の無さげな会社に居るのでG7
              #もっとも、上得意様も同様にDQNなので、割れ鍋になんとやらですが、その更に顧客は可哀想。

              >例えばその上流部分に宣言型言語を使うことによって
              >変更点をそれなりにうまく吸収、なんていう可能性はないものですかね?

              それは、変更点が「常に」その宣言型言語の領域に収まるか?という問いと等価ですね(^^;

              となると、どこならば生でコーディングしても良いのか?という問題にぶち当たりそうです。
              コーディングしちゃった部分に、後から変更が必要になることも有るだろうし、
              後から慌ててリファクタリングしたとしても、該当部分をコードから宣言型言語に「追い出す」ことが
              常に可能かどうかは保証無しじゃないかと。
              親コメント
        • > もしそういう環境があったとして、どういうところがうれしいですか?
          わたしは、WriteOnceRunAnywhereなところ、ですかね。
          そしてなにより、LearnOnceRunAnywhere(?)なところでしょうか。
          XML系の各種技術の(唯一の?)利点はここにあるかと。
          #それだけに、Ruby標準ライブラリのREXMLに落胆する・・・

          > おおむね優等生な言語なので、癖で悩むってことはあまり無いです。
          ですよね、言語仕様はきわめて‘自然’なものに感じます。
          悩むとしたら貧弱な標準ライブラリ・・・。

          > なにせ上記って、考えようによっては、それこそ「Pipe世界があればOOP要らないっしょ」と
          目標を実現するための適切なPipeラインを張り巡らせるのがつらいから、OOPを使うのでは?
          Pipeラインを張り巡らし、メンテナンスできるWizardがいれば苦労はしない、と。

          #普通にPipeラインを張れる大きさだったら、そりゃPipeのほうが楽ですよね。
          #だからRubyでも非OOPな記述が出来るようになっているわけで。

          > それぞれの言語で囲い込みが起きてしまうのはあんまりうれしくない。
          現状を見るに、囲い込みが起きるとしたら、言語でなく一つ深い層になりそうですね。
          ラッパーは言語でなく仮想環境で、言語はそのスキンってことになるのかもしれません。

          > まあ字面としてのrubyには、流石に囲い込まれる価値はないでしょう。
          「Ruby」は、抽象的な現行環境ラッパーまたは新しいプログラミングの枠組みですよね?
          rubyのことではないと。
          Ruby2にはVM(名称:Rite)が載るそうなので、それなら・・・?

          > 例えばその上流部分に宣言型言語を使うことによって
          > 変更点をそれなりにうまく吸収、なんていう可能性はないものですかね?
          それって、CGI/Perlとかですと普通にやることですよね?
          これであっているのでしたら、それなりには吸収できます。
          #ずれてたらすみません^^;;
          親コメント
          • >悩むとしたら貧弱な標準ライブラリ・・・。

            そ、そうなんですか。
            あんまりテンコモリになってJavaになって(藁)も困るなぁと思っているもんで、
            組み込み&標準の奴は、素朴な数でいいかなとも。

            で、あとは、ライブラリのInstallと「Un」Installに不安がゼロならばOKです。
            尤も、UnInstallの不安がゼロな環境なんて、見たことが無いですが(^^;

            >目標を実現するための適切なPipeラインを張り巡らせるのがつらいから、OOPを使うのでは?
            >Pipeラインを張り巡らし、メンテナンスできるWizardがいれば苦労はしない、と。

            いや、あれはあの人独特のバックグラウンド(笑)も絡むと思います。

            というのは、まあ憶測ですが俺も少し経験的に判る話として、
            所謂「業務アプリ」ならばアレで大体いける、ってのが有るんだと思っています。
            業務アプリって、ほんと、処理とかなんとかについては「稚拙」なもので充分だ、
            っていうことが多いんで、その「稚拙」なものを確実に量産する方法として、
            何かOOP未満(藁)な手段が有る余地も有りそうだ、とは思います。

            #ちょっと低レベル(笑)な企業なら、UMLどころかClassすら未だに疎遠、ってことは大いに有り得ると思う。
            #個人的には考えるだけウンザリしますがね。

            つまり、大したことをやらないんです。
            例えばPipeラインは張り巡ら「さない」んです。あまり多くない数しか扱わない。

            で、問題は、それで済むソフトってのが、ソフト全体(?)の何割を占めるのか?なんですが…
            無論俺も正解なんか知りませんが…

            >Ruby2にはVM(名称:Rite)が載るそうなので、それなら・・・?

            うーん。どうなんでしょう。
            Riteがどれだけ「広い」ものになるかに懸かってますね。
            笛を吹いてもRuby2以外誰も乗ってくれなければ、
            VMにする事の社会的(藁)意味は果たせなかった事になるわけで、
            これはマーケティング(藁)と運に依存するんでしょうね。
            親コメント
            • そ、そうなんですか。
              まぁ、「貧弱」というのはいい過ぎでしょうか。
              でも、言語自体が綺麗で期待してしまう分、そう思ってしまうんです。
              具体的にあげると、
              * Unicode系とSJIS/EUC/JIS間で文字コードを変換可能なライブラリ
                  (Uconv?Iconvは無茶ですよね)
              * W3C DOMの記法が使えるXMLライブラリ
                  REXMLも・・・まぁ、いいんですが、W3C DOM非対応だと引きます。
              って、この二つだけか、PHPのリファレンスを見ると恐ろしげなライブラリが並んでいて、
              それに比べるとー、とか思ってしまったのかな。。

              まぁ、あとはrequireなところとか、
              Perlのppmのようなものがないところとか。

              > 組み込み&標準の奴は、素朴な数でいいかなとも。
              自分のサーバーならば、数なくても入れればいいだけなのですが、
              レンタルサーバーを使っていると、最初からないともう増やせないんですよ。
              純Rubyなものならそれでも増やせますが、コンパイルが必要なものだともう無理。

              そんなわけで、Uconv相当のものは標準添付に入れて欲しい・・・

              > で、問題は、それで済むソフトってのが、ソフト全体(?)の何割を占めるのか?なんですが…
              8割は1行ですんだりして(笑
              冗談のつもりが、冗談じゃないような気もするのが怖い・・・

              > 笛を吹いてもRuby2以外誰も乗ってくれなければ、
              > VMにする事の社会的(藁)意味は果たせなかった事になるわけで、
              > これはマーケティング(藁)と運に依存するんでしょうね。
              まぁ・・・、わたしは乗ることを目論んでいたり(ぉ
              しかし、マーケティングは大切ですよね(笑
              親コメント
              • by G7 (3009) on 2004年06月27日 10時25分 (#577630)
                >* Unicode系とSJIS/EUC/JIS間で文字コードを変換可能なライブラリ
                >* W3C DOMの記法が使えるXMLライブラリ

                考えたら俺、UnicodeもXMLも、出来るだけ避けて通ってるなあ。
                UnicodeはEUCとかのNative(?)コードとの変換で苦しめられることばっかりだし
                (本来、苦しむ場面が有るのがおかしいじゃないですか。変換で苦しむのは結局Unicodeのデキが悪いからですよね)、
                ボヘミアンなScript言語派な俺様から見ればXMLはケーキ食ってる貴族様だし。

                >レンタルサーバーを使っていると、最初からないともう増やせないんですよ。
                >純Rubyなものならそれでも増やせますが、コンパイルが必要なものだともう無理。

                うーん。厄介ですね。
                (そのユーザから見ての仮想的な) /usr/local/lib を使わせてくれて、
                かつコンパイルジョブ(ジョブかょ。死語か?)も使えたら、いいんでしょうけど。
                あるいは鯖のアーキテクチャを公開してくれるとかぁ…

                >8割は1行ですんだりして(笑

                まあRubyだと1行とかでも色々有りでしょうね。
                蛇足ですがCだと1行でやれることなんて殆ど無いです。
                #「アプリ」をCで書くなんて今や自殺行為だと思うのでG7

                少なくともエラーチェックの綺麗化(つまりException)とGCが無いと
                コードが飛躍的にごちゃごちゃ&ダラダラになる。
                そして「意味の有る1つの処理の単位」がどこまで続くか一見して判りにくくなり、
                「コードをまとめるためにコメントを必要とする」ようになってしまう…鬱…
                親コメント

アレゲは一日にしてならず -- アレゲ見習い

処理中...