1. Ruby on Railsでなければできないことは実は無い “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.” 2. 社内にPHPの利用者が多く、Railsに移行するには再教育が必要 OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
3. Railsは冗長 DON’T WANT WHAT I DON’T NEED
4. phpは小さくて早い IT’S SMALL AND FAST
5. phpは自分好みにいじれる IT’S BUILT TO MY TASTES
6. phpだと自分でSQLを書ける I LOVE SQL
7. Ruby on Railsを学んだことでphpでもっといいコードが書けるようになった PROGRAMMING LANGUAGES AR
翻訳 (スコア:5, 参考になる)
“IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
2. 社内にPHPの利用者が多く、Railsに移行するには再教育が必要
OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
3. Railsは冗長
DON’T WANT WHAT I DON’T NEED
4. phpは小さくて早い
IT’S SMALL AND FAST
5. phpは自分好みにいじれる
IT’S BUILT TO MY TASTES
6. phpだと自分でSQLを書ける
I LOVE SQL
7. Ruby on Railsを学んだことでphpでもっといいコードが書けるようになった
PROGRAMMING LANGUAGES AR
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
“IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
PHPとRubyの対比という全体的な意味で捉えると、
この文には「PHPでのオブジェクト指向」なども含まれてるのかな。
個人的には、何でもオブジェクト化する必要は無いと思ってます。
特にWEBプログラミングは、文字列操作と組み込み型(リスト、ハッシュ)操作、
共通部分の関数化で済んでしまう、わりあい平坦な構造のプログラムが
多いです。こういうとき、OOPは単に冗長なことが多いです。
名前空間としてOOPするなら別ですが、本格的なOOPの導入は、
手続き型のコードでは可読性が損なわれてしまう程度に
複雑な処理が必要になってから考えればいいことだと思います。
その場合でも、ライブラリだけOOPするとか、段階的な
導入のほうが上手くいくと思います。
金槌で全てを叩くだけが方法ではないのです。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:2, 興味深い)
いろいろ反論ありそうですが。私も同感です。
私も(職業ではありませんが)大きなプロジェクトになりそうなものは
OOPで作り始めました。必要なライブラリもOOPで拡張するようになっ
てましたし、PHPのオブジェクトは書きやすいから好きでした。
(モノにはなりませんでしたが)
一方、つい最近、ごくごく簡単なPHPスクリプトを作りました。
HTMLとPHPが混じった綺麗とは言い難い内容ですが。
ニーズが少なすぎてメンテする人さえいない状態で、
とりあえず動くモノを早く提供する事が大切という点では、
OOPにこだわらずに作るのもアリだと思いました。
いくつかfunctionは使ったので、classにまとめることも
できたんでしょうけど。そこまでの必要性が無かったから
しなかった。それだけのこと。
#以上、チラシの裏でした
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
個人的には必ずしも OOP である必要は無いというのは同意するけど、OOP で書きたいと思ったときに
書くのが面倒な言語ってのも非常にストレスがたまる。なもんで、短いものなら関数型っぽく書けるし
基本的には OOP として書ける ruby は非常に楽。Python も悪くない。
Perlは手付にはいいんだけど書きつづけてくと自分が書いたコードが意味不明になってくんだよな。
いやもちろん Perl だけが悪いわけじゃないけど。
PHPにはできるだけ触れないように生きているので省略。言語自体を批判する気は全然ないけど、
毎週のように脆弱性がボロボロ出てくる言語でWebサーバを公開したくない。最近はそうでもないのかな?
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
Perlは以前試したけど、他人のソースを見ても、全く勉強にならずに挫折した。
それに、webとのやりとりで(なぜか)苦労したので使わない。
うちの場合、ローカルで動かす物ばかりなので、脆弱性うんぬんは関係ないのです。
は、PHPでも同じような。というか、どれでも出来そう。
私の場合、PHPなら出力が自動的にwebベースで出てくるのが非常に楽。
Cocoa(つーか、Interface Builder)やDelphiとかでダイアローグを作っても、
動くのは限られた環境なんだ・・・と思うと、(どの環境でも動く)web
プログラミングじゃないと無駄だなって思うようになったので。
出力がwebブラウザに必ず戻ってくるPHPが私には最適なのです。
HTMLの延長っぽく書けるのも、手軽なんですよね。(綺麗じゃないけど)
ターミナルからコマンドラインを使う人には、冗長かもしれません。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
Webアプリ程度のものでいいならWebアプリのエンジンを使うと結構楽そうです。
Ajaxだと多少複雑になりますが、まあなんとかなるか。
Flashあたりだと(バックエンドは)もっと複雑に成り得ますね。
もちろんクライアントが高機能化すればするほど、
サーバは楽をできるという面もあるんですが、
高機能なクライアントからの要求は「ときどき」複雑になります。
JSなしのWebアプリみたいに「ダム」な画面だと、
クライアントが複雑な要求をするということは有り得ないですが、
ダムでないクライアントは、何を要求してくるかわからない。(そのぶん色々やれます)
ところでJavaAppletなんかいかがですか?
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
Ajaxって「見栄えを良くする」方法に過ぎないと思うんですね。
webアプリを売り物にしてる人にとっては、客にアピールできるんだろうけど。
自分で使う物にはあんまり必要ないと思う。
Flashは紙芝居を作って遊ぶのに使ってます。HyperCardの代わりって感じ。
(本当は、HyperCard大好き! でも、真に置き換えになる物は見つからない)
Javaはいろんな意味でダメでした。理由が多くて書き切れません(笑)
Ruby on Railsは、以前Macへの導入の敷居の高さで挫折した・・・んだけど、
TigerにはRubyが入ってるのね。問題はMySQLか(起動が遅くなるので
あんまり入れたくないんだよね・・・)
素のPHPだとSQLの発行が面倒だったりするんで、データベースが必要な
用事があったらRoRを試すのもアリかもしれない。
PHPの、Railsもどきのフレームワークに決定版があれば、それもいいけど。
#ああ、完全にチラシの裏だわ
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
私はAjax…というかJSを使うこと…ではっきり変わり得ることといえば、
MouseMove(とかDragとか)が取得できるようになること、だと思っています。
なので、MouseMoveを活用して何かをやりたい(やらせたい)人でなければ、
たしかにAjaxは「xxxに過ぎない」でしょうね。
Flashとの違いは突き詰めれば効率というか処理速度でしょうね。
JavaAppletについては、最近出てきたJRubyやJavaFXでなら、まだしも楽に開発できるんじゃないか?と少し期待しています。起動が遅いことについては(ry(言葉を濁す
>本当は、HyperCard大
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
というか、RoRが魅力的に見えたのは、私の場合にはもっと基本的な所で、
「データベースにテーブルを作れば、データの入力・編集の部分は自動生成
される」って所です。テーブルを追加すれば、それなりにしてくれるし。
PHPでもPEARや何かを使えば、そうなるんでしょうけど。決定版が無い感じ。
また、HTMLとPHPの混在って(書き方にもよりますが)、まだ共存できてる
感じがするけど。SQLって言語は、PHPの中にいる場所が無いって感じがする。
具体的には、ダブルクォーテーションの中にSQL文を書くのが、分かりにくい。
> $a = "SELECT * FROM hoge WHERE name = 'poge';"
みたいに。文字列を繋げて、繋げて、長いSQL文(配列)になると、間違いを
探すのが大変だし。エラーの戻り方もPHPからかけ離れてくる。
↑
この不満をなんとかしようと、ライブラリを使ってみたけど、そんなに
便利になった気がしないので。結局そのままSQLを書くか、(データベースを
使わないで)直接ファイルに読み書きする方を考えちゃう。幸い、私が作る
ような物はパフォーマンスとか考える必要が無いので、それで十分なのです。
余談ですが。HyperCardでデータベースを作る場合。
バックグラウンドにフィールドを配置すれば、できあがり。
カード型データベースなんで、当たり前と言われそうですが。
FileMakerよりも簡単。
つまり、入れ場所のテンプレートさえ作れば、その入出力/編集の
基本的な部分のコードを書かなくていい、というのが私の望み。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
たとえばDelphiのDBコンポーネントも、多分そんな感じでした。
DB定義
↓
コンポ(Tableに一対一対応する非表示型コンポと、UIになる表示型コンポと)をWindowデザイナ上のWindowに貼る。
非表示型とUI型とが一体じゃなく役割分担してるのがDelphi流儀。
↓
Delphiを(正確にいえば上で貼ったコンポを)DBに接続する。
デザイナ上(実行前)でも接続できちゃうのが奇妙というか便利というか。
↓
コンポのプロパティをいじる。
Tableコンポは接続するTable名とか(望むならWhereとかも)をプロパティで設定。
UIコンポは
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
中身スカスカで正直びっくりする。
テクニックではなくて標準APIの使い方だけの説明がほとんどってどういうことよ。
通常SwingコンポーネントとDBの接続方法としてはBeansとのBindingライブラリを使って接続、JPAなどBeansとO/Rマッパで接続、というのが普通だと思います。
JBuilderはDelphiやBCBと同じコンポーネント構成です。ぽとぺたでできます。そのかわり開発環境がJBuilderに縛られ続けるので、パッケージ構成がころころかわるJBuilderはつらかったです。JBuilder6くらいまではかなりよかったのですが。
ですから、Javaでは、というのはあてはまりませんね。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
ああ。その落としどころが「まさにそれ!」って感じですねRubyは。
そういえば、たしかLL魂でMatzさんが言ってた
「ネタ」(つまりジョークであって本当ではない)のひとつとして、
「遅延評価機能のついた配列というかEnumerable」
というのがあったと記憶しています。
純粋なネタか、それとも第三者がライブラリとして作れば作れるものなのか、も、
私もいまだによく判っていませんが、
それ凄く欲しい!と思いました。
もしライブラリに出来るならばぜひください!(OpenSource公開してください!)>どなたか
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1, 興味深い)
C++やJavaみたいに「オブジェクト(とかクラスとか)を構築するのにかかる手間」が大きい言語では、回避したくなる気持ちも判りますが、
Rubyについてはそういう無駄なストレスが極限まで減らせれるよう言語デザインされてるんで。
そういう意味では、「オブジェクト指向」「スクリプト」言語っていうRubyの立ち位置は秀逸です。オブジェクト(指向)を気楽にスクリプティングできる言語。本当に必要な最小限の手間だけでオブジェクトをいじれる言語。
>文字列操作と組み込み型(リスト、ハッシュ)操作、共通部分の関数化で済んでしまう
たしかにRubyでも、このへんを(も)おおいに使って楽しますね。
正規表現リテラルとか、リスト(配列)リテラルとか、ハッシュリテラルとか、
あとSymbolやRangeのリテラルの存在も大きいです。
やっぱり幾つかの重要なオブジェクトがリテラルでサクっと書けるってのは重要。
文字列リテラルのない言語なんて誰も使いたくないでしょう。それの延長です。
そういう意味では、正規表現もハッシュもリテラルで書けないJavaは、つらいですね。
特に正規表現なんてUNIX Cで正規表現使うのと同じくらい面倒で、使う気にならない。
気軽に書けるってことは導入を躊躇しなくて済むということで、そのぶんご利益は広がります。
Rubyだとそれにくわえてもう1つ。
「(無名)関数のリテラル」ってのが重要な位置を占めます。
というか、これを重要な位置に据えることで、更にコーディングが楽になる。
いわゆるイテレータとかブロックとかいうあれですね。
Ruby(など)はこの技術の恩恵をおおいに受けてる。
そのぶん更にコードがシンプルで読み書きしやすくなる。
で、オブジェクト/クラスを作るのが楽だという性質によって
更にコーディングしやすさに拍車をかけてくれるのがRubyです。
特にいいのは、クラス定義機能というよりは、
includeやextendなどの
クラス混ぜ混ぜ機能や
特異メソッド機能のあたりですね。
これで「OOPがぐっと身近に」なります。
>手続き型のコードでは可読性が損なわれてしまう程度に
>複雑な処理が必要になってから考えればいいことだと思います。
そうかなあ?最初からOOP的に考えておいたほうが楽だと思います。
というのは、「途中からOOP流にコンバートする」のは凄く大変だからです。
いちから書くより多分ずっと大変です。
手続きベースかOOベースかの違いって奴は、実装だけじゃなく考え方(デザイン)まで影響してしまいますので、さかのぼらないとならない部分が多すぎ。
挫折する人らの何割かって、もしかすると、
途中でコンバートしようとして挫折してるんじゃないかな?
それ一番難しい作業ですから。最初からやったほうが絶対楽。
あと、同じことはOOPに限らないと最近思っています。
たとえば「関数型言語」ぽい考え方も、最初から少し導入しておいたほうが、つくりが綺麗になると思います。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:2, 興味深い)
とおっしゃっていますが、 私はこの意見に全面的賛成はできないという立場です。 複雑な問題に立ち向かう時、事前にしっかりとした設計をする必要があるのなら、 その設計段階にあたっては、 「オブジェクト指向」プログラミングすることによって、 何が得られ、何を諦めなくてはならないのか、 そこを明確に意識する必要があると思っています。
この前後のコメントで「いわゆるOOP」の利点について述べていると思われるところを拾ってみると(表現はちょっと変えていますが)、
というような考えがあるように読めます。
始めの2つは少々抽象的ですが、3つ目は
の表現から、 おそらく、 「いわゆるOOP」によりプログラムのモジュール化ができる、 ということを述べているのだと思われます。 上に列挙した1番目の考えも、同コメントに 「名前空間としてOOPするなら別」「ライブラリだけOOP」といった表現があることから、 やはりモジュール化についての考えを述べているようにも読めます。
実はこのコメントで主張したい二つの点の内の一つはここなのですが、 「プログラムを綺麗にモジュール化するために、 『オブジェクト指向』は本当に必須なのか」を考えてみて欲しいのです。
確かに、C++やJavaといった、いわゆる「オブジェクト指向言語」では、 モジュール化の仕組みとクラスベースオブジェクトシステムが密接に関係しています。 というより、むしろ、モジュール間の階層構造等の関係や、 名前空間の分離、名前の隠蔽や公開といった仕組みが言語仕様上大幅に省略され、 代わりにクラスベースオブジェクトシステムの上のクラスの階層構造や クラスの定義が、そうしたモジュール機能を肩代わりしています。 このため、プログラマは、自分が 「オブジェクト指向」による恩恵を得ているのか、 「モジュール化」による恩恵を得ているのか、 明確に意識することが難しくなっています。 本当に必要だったのは、「オブジェクト指向」ではなく、 「モジュール化」だった可能性はありませんか?
さて、「いわゆるOOP」の機能の一部を 「モジュール」と言い換えるかどうかはともかくとして、 それ以外の部分に「オブジェクト指向」を導入して失うものが無いなら、 それはそれで問題はないはずです。 では、実際に「オブジェクト指向」で失うものは有るのでしょうか?
元コメントの前後を見ると「とりあえず動くモノを早く提供する(#1224227)」ために OOPしないのだ、という意見があるようですが、 ここではその考えは採りません。 最初に述べたように、このコメントでは「事前にしっかりとした設計」という大前提で考えます。
一旦立ち戻って、そもそも「オブジェクト指向」とは何でしょうか。 これは人により様々なことを言う人がおり、 前述の「モジュール化」の機能もオブジェクト指向に含めて述べる人もいます。 とはいえC++やJavaにおけるモジュール化機能は、 「オブジェクト指向」は「オブジェクト指向」でも、 クラスベースオブジェクトシステム前提となっているので、 例えばJavaScriptのようなプロトタイプベースオブジェクトシステムではそのまま当てはまらない要素が多く、 そのためこのコメント中では、「モジュール化」は「オブジェクト指向」の必須機能ではないとしました。
クラスベースオブジェクトシステムとプロトタイプベースオブジェクトシステムで共通する要素はいくつかありますが、 私の知る限りほとんどすべての「オブジェクト」の定義に登場する要素は、
の二つです。 「メッセージ」と言っているのはアクター理論からの借り物ですが、 Smalltalk始め多くの「オブジェクト指向言語」は、 「メソッドの呼び出し」という形でメッセージを受け取って、 インスタンス変数を変化させる、という機能をほぼ必ず持っています。
私がここで「オブジェクト指向にしない理由」の一例として挙げたい点が、 正にここにあります。
つまり、「オブジェクト指向」の設計においては、 「内部状態の変化するオブジェクト」がお約束のように登場してきます。 「オブジェクト指向プログラミングは綺麗なプログラミング」と思い込んで設計をすると、 そこに何の疑問も生じないのですが、 実はここで「綺麗なプログラム」と考えられる性質の一つを、 無意識に捨てているの
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:2, 興味深い)
>「いわゆるOOP」によりプログラムのモジュール化ができる、ということを述べているのだと思われます。
元の人がどう意図したかは知りませんが、その解釈は違うかも知れませんね。
OOPがアクセスを抑止(あるいは警告?)するのは、
ほかの「クラス」へのアクセス(だけ)じゃなく、
ほかの「インスタンス」へのアクセスも、です。
もっとも、C++/Javaがそういう設計なもんだから誤解されることが多いですね。
privateなのに「ほかのインスタンス」へアクセス可能だってのは、まずい設計だと思っています。
それこそC++/Java作者がOOPとモジュールプログラミングを混同してたんじゃないの?と疑ってしまう。
この面はそれこそRubyのほうがマシです。
>オブジェクトは内部状態を持つ。
データベースも含めて「状態」を考えると、
少なくともRailsがターゲットとしてるような「普通のWebアプリ」において(も)、
「内部状態を持つ」はそれなりに成り立ってると思います。
RailsのObjectが、というよりは、細かくいえば「(RailsのO/Rマッピング機能である)ActiveRecordのObjectが」ですね。
>「参照透過性」
たしかに完全な参照透過性とOOPは相性が悪いですが、「関数型もどきコーディング」のご利益とOOPとくらいならば両立できるように見えます。
まさにその実例のメジャー(今となっては)なものが、Rubyのコーディングだと思われます。
そういう意味では、「ほかのメジャー言語と似てない機能は使わない」という方針で書かれたRuby入門書は、筆者には悪いけどゴミだと思っています。初心者だっていうならむしろ「最初から」Rubyの関数型っぽい面とかを使いまくったほうがいい。あれはJavaとかに染まった人のほうが抵抗感を感じるはず。
>boost前提で良いのなら、「オブジェクト指向」だけでなく、かなり「関数型」の考えを取り入れたプログラミングが
ああ。それはありますね。
もっともコーディングの面倒&難解さから、Rubyの楽さと比べる気にもなりませんが。
>Firstclass objectとしてのcontinuationや、 monadは、案外web application開発と相性が良いのではないか、なんてアイデアもあるようです。
Continuationについては、KahuaというかGauche…の中の人…の話が、猛烈に秀逸なうえにNativeジャパニーズで読めるので、凄くいいです。Shiroさんは日本の宝の1つだと思う。あとコミュニティもね。
あの人のサイトを骨の髄まで読むといいと思います。Kahuaでは実際にCont.が Webアプリ構築フレームワークの中の中心(!)に据えられてますし、いっぽうで「(Gaucheを実装してる)Cのいわゆるスタックは、Cont.と相性最悪である」などといった現実面での嘆きとか、そういう色々な視点からの話が読めます。
>結局PHPに戻って、2年後に
PHPじゃなくRubyに戻る、っていうコースも有るかも。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
> OCamlのオブジェクトは参照透過性をあっさり捨てているので、プログラムの部分部分で、結局どちらかを選択することになりますが。
とありますが、OCamlのオブジェクトで実質的に参照透過性が失われるのは、あくまでもmutableなインスタンス変数を含みその値を変化させた場合です。逆に言えばmutableを一切指定しなければそれだけで参照透過性を保ちながらオブジェクト指向することが出来ます(これは例えばレコード型におけるのと同様のことです)。このため参照透過性を理由にしてモジュールとクラスの二者選択を迫る必要性はありません。これがオブジェクト指向的であるのかについては多少疑問の余地が残るところであり、また現実的にはそんなところで頑張るなら全部モジュールだけで書いちゃっていいんじゃない?と思ったりもしますが、クラス継承の側面だけを利用したい場合やstructural subtypingによる柔軟な型運用だけを利用したい場合などには、実際私はこうしたことを行なっています。
なので、一応、OCamlにおけるオブジェクトが参照透過性を完全に捨てているわけではないことを補足しておきます。もちろんプログラマがそれを捨てることを選択しても全然構わないし、実際捨てる場面の方が多いかも知れませんが、それを保ちながら書くことは出来ます。また他の言語においても同様の制約を課せば実質的に参照透過性を保ちながらオブジェクト指向ができるのだろうと思います。ただ、こんなのOOPじゃない!と言われても仕方ないような気はします。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
プログラムの内部状態という「猛獣」と如何に付き合うか?について人類が考えた、
2つの方法論ですね。
2つで全てではないですが、メジャーな2つであるのは確か。
その2つがたまたま技術的に水と油で相容れないのは、不幸で残念な(残念ですが)事実ですね。
かたやOOP。
はっきり言って古典的なやり方の延長でしかないが、
状態を持つ「単位」を小さくすれば把握しやすくなるだろうと踏んで小さくし、
ついでにキャッチーにするため(?)にそれらを「モノ」として捉えることを推奨するという、
論理的裏づけは薄いが感性には訴えやすいやり方。
かたや参照透過性。
状態…の変化…が有る
今だ、つっこめ! (スコア:0)
技術的にではないですよね?
方法論的に違うんだから、必然的に相容れないのではないでしょか。
> そして、やりようによってはハイブリッド派も成立可能。
興味本位でお聞きするのですが、
例えばどんな方法をさしてますか?
Re:今だ、つっこめ! (スコア:1, 参考になる)
元コメントのACさんではありませんが、
の答になりそうな方法を知っている範囲で……。例: Flavors, CLOS, OCaml等のオブジェクトシステム
実例は無さそう。 OOPではないけれど、副作用のある処理をstreamで扱うのは昔のHaskell (Haskell 1.0のStream-based I/O)の方法。
参考: Lazy Functional State Threads [gla.ac.uk]
余談: Web applicationのような一見非関数な処理も、DBに対するstate transformerと見れば、関数的に記述できる。
例: Clean言語は"uniqueness types"を使うことでこれを実現している。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
OOPでないと生きていけない体に (スコア:1)
仕事ではそりゃ言語を自分で選ぶことはできませんし、
言われたままの規約に従ってコーディングするしかありませんが、
自分のために各ツールなんかは C++ + boost がないと生きていけない…
フラットな構造になってるとなんか覚えておかなきゃならないことが
多すぎて困りませんか?「お前、アクセスされる必要もないのに
なんでそこにいるんだよ、グローバル?あっちいけよ。」
とか、そんな感じです。
屍体メモ [windy.cx]
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1, おもしろおかしい)
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
Railsはアウトですか?
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
もしかして class を使うか使わないか?
手段と目的 (スコア:0)
> この文には「PHPでのオブジェクト指向」なども含まれてるのかな。
含まれていません。単に「何が」できるかという意味で両者に違いがないと言っているだけで、
「どうやって」実現するかという意味で違いがないとは言っていません。