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

OO言語へと歩を進めるPHP5」記事へのコメント

  • Perlの (スコア:0, 興味深い)

    by Anonymous Coward
    二の舞ですか?
    Perl4からPerl5にバージョンがあがったときも、
    オブジェクト指向的な要素を取り入れましたが、
    ほとんど使われてないんじゃないのかな。
    だいたい、PerlにしろPHPにしろオブジェクト指向が
    やりたくて選択したわけじゃなくて
    • Re:Perlの (スコア:2, 参考になる)

      便利ですよ。OOなコードも良く見かけます。とくに海外では。

      少し規模のあるアプリケーションを書こうと思ったりコードを再利用しようと思うと PHP でも OOP にした方が楽だと私は感じています。

      コードを追いかける時も労力が違います。
      全てのシーンで OO 万歳とは言わないけどオブジェクト指向でなければ耐えれないシーンが増えてきているのも確かでは。

      # でないと誰も使わないかと。

      Ruby などに比べると月とすっぽんですが一度慣れてしまえば迷路としか思えない function と include には
      • スクリプト言語によくもとめられる「労力を省く」という観点からすると、クラスというものは結構いいと思いますね。
        引数とか、シンプルで、わかりやすくかけますし。
        パクリもしやすいと。

        Rubyなんかと違って、
        「すべてがオブジェクトで無い
        というところに、可能性を感じております。
        • どういう可能性?
          • やりたい処理が目の前にあるとき、設計を省ける可能性。
            --
            # mishimaは本田透先生を熱烈に応援しています
            • すべてがオブジェクトだと、使う側がいちいち設計しないといけないの?
              • うん、オブジェクト指向をめざす限り、多少の設計は必要でしょ。

                >「すべてがオブジェクトで無い」

                という言葉は、文脈からみて
                「オブジェクト指向でないデータの扱い方も考えてある」
                という意味にとったけど。

                (だって、単なるデータだって「これはほげほげオブジェクトです」
                って言われたらオブジェクトなんだから、
                オブジェクト指向でない「オブジェクト」という言葉には意味ないし)
                --
                # mishimaは本田透先生を熱烈に応援しています
                親コメント
              • なぜ、すべてがオブジェクトだと目の前の仕事をこなす程度でも
                オブジェクト指向の実装を目指す必要があることになるの?
                後半の予防線はどうでもいいです。というかもういいや。元投稿者の答えを待つ。

                すべてがオブジェクトであるということが奪う可能性って何かなーと興味がある。
              • 「感じて」というくらいですので、ちゃんと言葉で言えるかどうか、、、。

                WEB用のスクリプト言語となると、1実行でそれほど複雑な処理をするわけではないです。
                となると、手続き型の方が、シンプルに記述できるのではないかと。
                さらに、複雑なデータを処理する部分にオブジェクト指向を持ち込むと、
                もっとシンプルさを高められるのではないか、
                というようなイメージです。

                #うーん、ちょっとちゃうような気もするが。
                親コメント
              • haruxさんはクラスを定義して使うようなオブジェクト指向言語を念頭においているのかな。

                無名クラスがon-the-flyで作れるとか、Selfみたいにクラスなんてそもそも無くて全部インスタンスだとか、そういう言語ならわりと自然にone-linerからシンプルに記述できそうな気がする。

              • > すべてがオブジェクトであるということが奪う可能性って何かなーと興味がある。

                あー、そういう意味の質問なのね。
                それならたとえば、部分的に宣言型で処理を記述できるような言語の可能性はどう?
                全てをオブジェクトで扱おうとすると、
                このような言語の発展の仕方ができなくなる。

                #もういいや、って言ってるのに何だけど。
                --
                # mishimaは本田透先生を熱烈に応援しています
                親コメント
              • Re:中途半端さがイイ! (スコア:3, すばらしい洞察)

                by matz (2690) on 2003年04月02日 0時48分 (#291305) ホームページ

                WEB用のスクリプト言語となると、1実行でそれほど複雑な処理をするわけではないです。
                となると、手続き型の方が、シンプルに記述できるのではないかと。


                そんなプログラムでは手続き型言語とオブジェクト指向言語で差はでないような気がします。
                特にRubyとかでは。誤解の再生産に反対。
                --
                まつもと ゆきひろ /;|)
                親コメント
              • 個人的には、
                「オブジェクト」という考えが、後になって取得したものなので、
                「オブジェクト」が出てこない方が「シンプル」に感じられるのですよ。

                puts("Hello!")
                のような記述があるじゃないですか?
                ということは、オブジェクトの存在自体を隠すことが、何らかの利点があるということですよね。

                PHPだと、printとか元々オブジェクトじゃなくて、
                それが「シンプル」に感じられるのです。

                何故だろう?と考えると、単なる慣れのような気もしてきましたが、
                でも慣れじゃない、と考えることでPHPのオブジェクト指向の独自性を出せるのかもと思っているのですけれども、、。
                親コメント
              • 発想がシンプルなのと、記述の仕方がシンプルなのは別問題だと思うのですが?
                --
                This cookie has a scrap of paper inside. It reads:
                If you can't learn to do it well, learn to enjoy.
                親コメント

              • puts("Hello!")
                のような記述があるじゃないですか?


                Rubyにもありますが、それがなにか?
                「オブジェクト」という言葉でなにを表現しようとしてますか?
                --
                まつもと ゆきひろ /;|)
                親コメント
              • >「オブジェクト」という言葉でなにを表現しようとしてますか?

                様式上のはなしになりますが、
                オブジェクト.関数名という形式ということになるでしょうか。
                あと、かえり値を得るのにこの形式で複数回の関数コールをするということ。

                あと、puts("Hello!") の件は、なぜputsは関数の前のオブジェクト名がないのでしょうか?
                親コメント
              • by matz (2690) on 2003年04月02日 23時15分 (#291778) ホームページ

                様式上のはなしになりますが、
                オブジェクト.関数名という形式ということになるでしょうか。
                あと、かえり値を得るのにこの形式で複数回の関数コールをするということ。


                そういう形式(メソッド呼び出し)しか許さないオブジェクト指向言語ってSmalltalkしか知らないんですが。世の中に存在する数多くのオブジェクト指向言語が、haruxさんのおっしゃる「中途半端」な形式を許しているのに、それをことさらにPHPの特徴として取り上げるのは「誤解の再生産」ではないかと。

                「オブジェクト=メソッド呼び出し」というのは短絡的に過ぎるのでは。
                --
                まつもと ゆきひろ /;|)
                親コメント
              • >puts("Hello!") の件は、なぜputsは関数の前のオブジェクト名がないのでしょうか?
                概念としては、デフォルトオブジェクト(自分自身)は省略されると考えれば、納得できませんか?
                或いはプログラム全体を意味するグローバルオブジェクトは省略されると。
                そういう意味では、Cは全てのメソッドがグローバルオブジェクトのメンバ関数であるとなりますね(笑)
                親コメント
              • by G7 (3009) on 2003年04月05日 17時41分 (#293189)
                そういや、「関数形式」という発想には脱帽した記憶が有ります。
                #それがmatz氏のオリジナルかどうかという歴史問題は知りませんが。

                いわゆる関数の書式と、いわゆる伝統的(?)なOOPの書式とが、こんなかたちで邂逅するなんて…と。

                しかもprivateという概念の定義とも旨く絡んでいるし。
                C++とかDelphi(笑)とかのprivateの定義って、糞だと思う。
                クラスが同じなら違うインスタンスでも触れられていいのか?そんなもん制限として意味あるのか?と、以前から思っていました。
                なので、クラスじゃなくインスタンス単位でアクセス制限されるrubyのprivateは
                「(アクセス制限全般が必要だと思うならば)必要なもの」っすね。

                しかも、それを実現するため(ってのか)に、privateだと「レシーバーを明示した書式では呼べない」ってのがナイス。
                そりゃ他のインスタンスに触れたら駄目なんだから、インスタンス名は指定する必要も無いわな。

                そして、地の文(ってのか)が実は巨大オブジェクト(笑)のprivate methodの「中」だと捉えれば、話が全部うまく繋がる。

                既に幾万の人が言ってることでしょうが俺も言います。これ、かっこいいです。

                ----

                それはそれとして、"hoge".print なんて書式も俺は結構好き。 "matz ruby".GoogleJ なんて感じ(違

                あと、STDOUT.print("hoge")なのか"hoge".print(STDOUT)なのか、つまりどっちが主(ってのか)なのかという問題も結局有るんだし。
                そして、よくあるprint("hoge")という書式のように、STDOUT(参加者のうちの一方)を暗黙化しちゃうと、
                却って「初心者の素直な理解」を阻害しちゃわないか?という心配すら、沸いてきます。
                まあ、慣れてくれば暗黙化や省略が有っても誤解せずその利便性だけを享受できますけど(rubyがまさにそうであるように)、ね。
                親コメント
              • by G7 (3009) on 2003年04月05日 18時04分 (#293195)
                >Cは全てのメソッドがグローバルオブジェクトのメンバ関数であるとなりますね(笑)

                ちなみにpublic methodはたった1つ「main()」だけですね(笑)。他は全部private。
                OSという「objectの外」から呼べるのはmain()だけ。(他にもアーキテクチャ依存で幾つかあるかも知れないが)

                ああ。動的ライブラリだと、その限りではないかな。
                もっともあれは methodは methodでもInstance methodじゃなくClass methodかなという気がするけど。

                ----

                ところで、スタンドアロン実行プログラムに話を絞って上のような考え方をすると、
                WindowsとUnix(つーかANSI C)との違いが、面白く捉えられます。

                main()って、Class methodなんですよね。というかconstructor。
                つまり我々は、constructorしか公開されてないObjectを、日々扱っているわけです(笑)。

                methodは、処理番号みたいなものをやり取りするという運用ルール(笑)を介在させることで、
                method自体の数をケチることが出来ます。
                methodA(), mehtodB()…じゃなく、method("A"), method("B")…とすることが出来るわけです。

                ただし、こうやってもケチれない面がありまして、それは「recieverが何か」という問題です。
                どのオブジェクトについてるmethodなのか?という問題です。

                ところで、class methodとinstance methodって、つまりはreceiverが違うんですよね。classというものとinstanceというもの。

                だから、実行プログラムObject(笑)にも、最低2つのmethodが要る、と思うんです。
                class methodとinstance methodが。

                で、翻って考えるに、main()だけ(笑)の世界だと、class methodしかないわけです。
                main()は実行「ファイル」へのmethod(プロセスobjectを産むconstructor)であって
                実行「プロセス」へのmethodではない。

                そういやmain()な世界のプログラムって、シグナルでも無い限り、
                いったん起動したプログラム(プロセス)に話しかける方法が無いですよね。
                まあプロセス自体が1つのThead Objectでもある(笑)という面もありますが、
                こんなわけで、Unixのプログラムは「走り出したら最後まで手を出せない」わけです。
                #IOは別問題ですので話は略。

                一方Windowsだと、これが両方あるんですよね。
                WinMain()はconstructorなclass methodだし、WinProc()はイベント(処理番号)を引数で与えられるinstance method。

                unixモデルとWindows(に限らないだろけど)モデルとを、無理矢理Objectに準えて考えると、ちょっと面白かったです。

                そういや知人(笑)に、Unixとかみたいに処理権限を丸々アプリに渡すんじゃなく、最初からイベント駆動を前提にする、という組み込み(小規模)OSを作りたいと言ってる人がいたなあ。
                OSから処理依頼が来たら、処理をちょちょいと走らせて、終わったら制御をOSに戻す。擬似マルチタスクともいうけど。

                アプリを信頼しないという考え方から言えば、Unixのように一見実行権を渡した上で上位機能で強制終了できるようにするって手も有ろうけど、
                強制終了機能の必要性と、アプリに実行権を渡してしまうのが常に良いことなのかどうかとは、別問題なんだよなあ。
                親コメント

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

処理中...