アカウント名:
パスワード:
ＷＥＢ用のスクリプト言語となると、１実行でそれほど複雑な処理をするわけではないです。 となると、手続き型の方が、シンプルに記述できるのではないかと。
puts("Hello!") のような記述があるじゃないですか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
Perlの (スコア:0, 興味深い)
Perl4からPerl5にバージョンがあがったときも、
オブジェクト指向的な要素を取り入れましたが、
ほとんど使われてないんじゃないのかな。
だいたい、PerlにしろPHPにしろオブジェクト指向が
やりたくて選択したわけじゃなくて
Re:Perlの (スコア:2, 参考になる)
少し規模のあるアプリケーションを書こうと思ったりコードを再利用しようと思うと PHP でも OOP にした方が楽だと私は感じています。
コードを追いかける時も労力が違います。
全てのシーンで OO 万歳とは言わないけどオブジェクト指向でなければ耐えれないシーンが増えてきているのも確かでは。
# でないと誰も使わないかと。
Ruby などに比べると月とすっぽんですが一度慣れてしまえば迷路としか思えない function と include には
中途半端さがイイ！ (スコア:1)
引数とか、シンプルで、わかりやすくかけますし。
パクリもしやすいと。
Rubyなんかと違って、
「すべてがオブジェクトで無い」
というところに、可能性を感じております。
Re:中途半端さがイイ！ (スコア:0)
Re:中途半端さがイイ！ (スコア:1)
# mishimaは本田透先生を熱烈に応援しています
Re:中途半端さがイイ！ (スコア:0)
Re:中途半端さがイイ！ (スコア:1)
＞「すべてがオブジェクトで無い」
という言葉は、文脈からみて
「オブジェクト指向でないデータの扱い方も考えてある」
という意味にとったけど。
# mishimaは本田透先生を熱烈に応援しています
Re:中途半端さがイイ！ (スコア:0)
オブジェクト指向の実装を目指す必要があることになるの？
後半の予防線はどうでもいいです。というかもういいや。元投稿者の答えを待つ。
すべてがオブジェクトであるということが奪う可能性って何かなーと興味がある。
Re:中途半端さがイイ！ (スコア:1)
ＷＥＢ用のスクリプト言語となると、１実行でそれほど複雑な処理をするわけではないです。
となると、手続き型の方が、シンプルに記述できるのではないかと。
Re:中途半端さがイイ！ (スコア:3, すばらしい洞察)
そんなプログラムでは手続き型言語とオブジェクト指向言語で差はでないような気がします。
特にRubyとかでは。誤解の再生産に反対。
まつもと ゆきひろ /;|)
Re:中途半端さがイイ！ (スコア:1)
「オブジェクト」という考えが、後になって取得したものなので、
「オブジェクト」が出てこない方が「シンプル」に感じられるのですよ。
puts("Hello!")
のような記述があるじゃないですか？
ということは、オブジェクトの存在自体を隠すことが、何らかの利点があるということですよね。
PHPだと、printとか元々
Re:中途半端さがイイ！ (スコア:1)
Rubyにもありますが、それがなにか？
「オブジェクト」という言葉でなにを表現しようとしてますか？
まつもと ゆきひろ /;|)
Re:中途半端さがイイ！ (スコア:1)
様式上のはなしになりますが、
オブジェクト．関数名という形式ということになるでしょうか。
あと、かえり値を得るのにこの形式で複数回の関数コールをするということ。
あと、puts("Hello!") の件は、なぜputsは関数の前のオブジェクト名がないのでしょうか？
Re:中途半端さがイイ！ (スコア:1)
概念としては、デフォルトオブジェクト（自分自身）は省略されると考えれば、納得できませんか？
或いはプログラム全体を意味するグローバルオブジェクトは省略されると。
そういう意味では、Ｃは全てのメソッドがグローバルオブジェクトのメンバ関数であるとなりますね（笑）
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のように一見実行権を渡した上で上位機能で強制終了できるようにするって手も有ろうけど、
強制終了機能の必要性と、アプリに実行権を渡してしまうのが常に良いことなのかどうかとは、別問題なんだよなあ。