アカウント名:
パスワード:
haruxさんはクラスを定義して使うようなオブジェクト指向言語を念頭においているのかな。
無名クラスがon-the-flyで作れるとか、Selfみたいにクラスなんてそもそも無くて全部インスタンスだとか、そういう言語ならわりと自然にone-linerからシンプルに記述できそうな気がする。
ＷＥＢ用のスクリプト言語となると、１実行でそれほど複雑な処理をするわけではないです。 となると、手続き型の方が、シンプルに記述できるのではないかと。
puts("Hello!") のような記述があるじゃないですか？
様式上のはなしになりますが、 オブジェクト．関数名という形式ということになるでしょうか。 あと、かえり値を得るのにこの形式で複数回の関数コールをするということ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
Perlの (スコア:0, 興味深い)
Perl4からPerl5にバージョンがあがったときも、
オブジェクト指向的な要素を取り入れましたが、
ほとんど使われてないんじゃないのかな。
だいたい、PerlにしろPHPにしろオブジェクト指向が
やりたくて選択したわけじゃなくて
Re:Perlの (スコア:2, 参考になる)
少し規模のあるアプリケーションを書こうと思ったりコードを再利用しようと思うと PHP でも OOP にした方が楽だと私は感じています。
コードを追いかける時も労力が違います。
全てのシーンで OO 万歳とは言わないけどオブジェクト指向でなければ耐えれないシーンが増えてきているのも確かでは。
# でないと誰も使わないかと。
Ruby などに比べると月とすっぽんですが一度慣れてしまえば迷路としか思えない function と include には戻れません。
PEAR や PHPDocumentor などツールも充実しつつあります。
日本語Windowsでエラーを吐くので使えませんが著名なPHPエディターの PHPEdit には PHPDoc ツールが仕込んであり、一発でドキュメントを吐いてくれる [backendmedia.com]ようで普及に一役買っているようです。
中途半端さがイイ！ (スコア:1)
引数とか、シンプルで、わかりやすくかけますし。
パクリもしやすいと。
Rubyなんかと違って、
「すべてがオブジェクトで無い」
というところに、可能性を感じております。
書くは天国、読むは… (スコア:1)
OOP好きな俺が言うのもなんですが、
(自分で何をどうしたいか判ってる状態で)書くのは確実に楽になりますが、
読むのはどうかな？と思うことが有ります。
よく言われることですが、処理の流れが見えにくくなりますね。
まあCでも関数が多くなるとそれと近い状況になりそうですが、
OOPだとそれに加えて、多態が(デフォルトで)出来るので、
今どこを通っているのかを追うには、そもそもクラス構成を理解してないと
(ちなみに、ある変数にどの場面でどのクラスのオブジェクトが入ってるかの問題なので、
静的なクラス図だけじゃ情報不足です。動的なほうも判ってないとね)
先に進めない、ってことが…
その見えにくさを押し進める(笑)ものが、
テンプレートメソッドパターン(穴埋め問題を解くのは未来に任せる)であり、
ストラテジーパターン(具体的にどう処理するかは未来に任せる)であり、
チェインオブレスポンシビリティーパターン(どこまで行ったら解決してくれるのかは実行時に任せる)であり…(^^;
ま、OOP以前だと逆に「使って天国、作って地獄」と言われてたわけですから、これでオアイコかなという気もしますが(^^;
あと、説明になる情報(javadocにせよ「ソース自体が(読めるような)ドキュメント(になってる)」にせよ)があれば
結局なんとかなる、とも言えないわけではないんで、アレですが。
Re:中途半端さがイイ！ (スコア:0)
Re:中途半端さがイイ！ (スコア:1)
# mishimaは本田透先生を熱烈に応援しています
Re:中途半端さがイイ！ (スコア:0)
Re:中途半端さがイイ！ (スコア:1)
＞「すべてがオブジェクトで無い」
という言葉は、文脈からみて
「オブジェクト指向でないデータの扱い方も考えてある」
という意味にとったけど。
（だって、単なるデータだって「これはほげほげオブジェクトです」
って言われたらオブジェクトなんだから、
オブジェクト指向でない「オブジェクト」という言葉には意味ないし）
# mishimaは本田透先生を熱烈に応援しています
Re:中途半端さがイイ！ (スコア:0)
オブジェクト指向の実装を目指す必要があることになるの？
後半の予防線はどうでもいいです。というかもういいや。元投稿者の答えを待つ。
すべてがオブジェクトであるということが奪う可能性って何かなーと興味がある。
Re:中途半端さがイイ！ (スコア:1)
ＷＥＢ用のスクリプト言語となると、１実行でそれほど複雑な処理をするわけではないです。
となると、手続き型の方が、シンプルに記述できるのではないかと。
さらに、複雑なデータを処理する部分にオブジェクト指向を持ち込むと、
もっとシンプルさを高められるのではないか、
というようなイメージです。
＃うーん、ちょっとちゃうような気もするが。
Re:中途半端さがイイ！ (スコア:0)
haruxさんはクラスを定義して使うようなオブジェクト指向言語を念頭においているのかな。
無名クラスがon-the-flyで作れるとか、Selfみたいにクラスなんてそもそも無くて全部インスタンスだとか、そういう言語ならわりと自然にone-linerからシンプルに記述できそうな気がする。
Re:中途半端さがイイ！ (スコア:1)
あー、そういう意味の質問なのね。
それならたとえば、部分的に宣言型で処理を記述できるような言語の可能性はどう？
全てをオブジェクトで扱おうとすると、
このような言語の発展の仕方ができなくなる。
＃もういいや、って言ってるのに何だけど。
# mishimaは本田透先生を熱烈に応援しています
Re:中途半端さがイイ！ (スコア:3, すばらしい洞察)
そんなプログラムでは手続き型言語とオブジェクト指向言語で差はでないような気がします。
特にRubyとかでは。誤解の再生産に反対。
まつもと ゆきひろ /;|)
Re:中途半端さがイイ！ (スコア:1)
「オブジェクト」という考えが、後になって取得したものなので、
「オブジェクト」が出てこない方が「シンプル」に感じられるのですよ。
puts("Hello!")
のような記述があるじゃないですか？
ということは、オブジェクトの存在自体を隠すことが、何らかの利点があるということですよね。
PHPだと、printとか元々オブジェクトじゃなくて、
それが「シンプル」に感じられるのです。
何故だろう？と考えると、単なる慣れのような気もしてきましたが、
でも慣れじゃない、と考えることでPHPのオブジェクト指向の独自性を出せるのかもと思っているのですけれども、、。
Re:中途半端さがイイ！ (スコア:1)
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:中途半端さがイイ！ (スコア:1)
Rubyにもありますが、それがなにか？
「オブジェクト」という言葉でなにを表現しようとしてますか？
まつもと ゆきひろ /;|)
Re:中途半端さがイイ！ (スコア:1)
様式上のはなしになりますが、
オブジェクト．関数名という形式ということになるでしょうか。
あと、かえり値を得るのにこの形式で複数回の関数コールをするということ。
あと、puts("Hello!") の件は、なぜputsは関数の前のオブジェクト名がないのでしょうか？
Re:中途半端さがイイ！ (スコア:2, 興味深い)
そういう形式(メソッド呼び出し)しか許さないオブジェクト指向言語ってSmalltalkしか知らないんですが。世の中に存在する数多くのオブジェクト指向言語が、haruxさんのおっしゃる「中途半端」な形式を許しているのに、それをことさらにPHPの特徴として取り上げるのは「誤解の再生産」ではないかと。
「オブジェクト＝メソッド呼び出し」というのは短絡的に過ぎるのでは。
まつもと ゆきひろ /;|)
Re:中途半端さがイイ！ (スコア:1)
概念としては、デフォルトオブジェクト（自分自身）は省略されると考えれば、納得できませんか？
或いはプログラム全体を意味するグローバルオブジェクトは省略されると。
そういう意味では、Ｃは全てのメソッドがグローバルオブジェクトのメンバ関数であるとなりますね（笑）
Re:中途半端さがイイ！ (スコア:1)
＃それが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がまさにそうであるように)、ね。
Re:中途半端さがイイ！ (スコア:1)
ちなみに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のように一見実行権を渡した上で上位機能で強制終了できるようにするって手も有ろうけど、
強制終了機能の必要性と、アプリに実行権を渡してしまうのが常に良いことなのかどうかとは、別問題なんだよなあ。