アカウント名:
パスワード:
独自の API を自分のビジネスに有利なように設計しやすいからでないでしょうか。
既存の言語にライブラリとして導入しても、そのライブラリは2級市民の位置にとどまる可能性が高い( Ruby の Rails は例外だが、 Android の API は Java言語上では2級市民 )
けれども言語ごと設計すれば、限度があるにせよ、かなりの自由度で必要なライブラリを標準の機能として導入できる。
別にRailsはRubyの言語設計で特別扱いなんて受けていませんよ。だからこそActiveSupportが作られたんでしょ(ActiveSupportは言語の既存クラスにRails流のメソッドを大量に追加するライブラリです)。そのActiveSupportにしても別に特別な考慮はされず、今までにコアライブラリに取り込まれたものはごく一部です。
外部からまるで一体に見えるのは、まあRubyとRailsがどちらもよくできているんでしょうな。
オープンクラスだから、メソッドが後からいくらでも生やせるってだけ。これがいいことなのかどうなのかは、意見の分かれるところだし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
独自のAPIを持ちたいからではないか (スコア:0)
独自の API を自分のビジネスに有利なように設計しやすいからでないでしょうか。
既存の言語にライブラリとして導入しても、そのライブラリは2級市民の位置にとどまる可能性が高い
( Ruby の Rails は例外だが、 Android の API は Java言語上では2級市民 )
けれども言語ごと設計すれば、限度があるにせよ、かなりの自由度で必要なライブラリを標準の機能として導入できる。
Re:独自のAPIを持ちたいからではないか (スコア:0)
別にRailsはRubyの言語設計で特別扱いなんて受けていませんよ。
だからこそActiveSupportが作られたんでしょ(ActiveSupportは言語の既存クラスにRails流のメソッドを大量に追加するライブラリです)。
そのActiveSupportにしても別に特別な考慮はされず、今までにコアライブラリに取り込まれたものはごく一部です。
外部からまるで一体に見えるのは、まあRubyとRailsがどちらもよくできているんでしょうな。
Re: (スコア:0)
オープンクラスだから、メソッドが後からいくらでも生やせるってだけ。
これがいいことなのかどうなのかは、意見の分かれるところだし。
Re: (スコア:0)