1

のような一般的な長時間実行プロセス環境のRubyアプリケーションでは一般的な問題のように思われますがrails server、開発の苦痛を軽減するためのクラスの再読み込みは困難ですが、解決する必要のある重要な問題です。

言語はstdlibによって定義されている定数を最もよく知っており、どの定数がどのファイルからいつロードされたかを知るために、そしてもちろんそれらを再ロードすることを提案するために完全に配置されていることに私は驚かされます。

require 'foo'によって定義する複雑なケースがありますBarが、それを追跡するのはそれほど難しくありません。さらに、define_const使用されたケースも泥だらけになります。スレッド化されたロードはさらに別の問題ですが、スレッドがディスクのファイルの現在の状態から自分自身を再ロードできるようにするケースを実際に見ることができます。(より高速なテストサーバーが一番の考えです)

それは言語機能であるべきであり、多くの、多くの異なる人々が解決策を展開する必要があるものではないようです。

要約すると、これが言語機能ではないのはなぜですか?使用プロファイルは、ほとんどの場合、長時間実行されている開発サーバーに限定されていますが、そうあるべきだと思われます。

ここでの他の質問は、「なぜRailsは組み込みのDRBモデルを使用して開発サーバーを高速化し、すべてのクラスの再読み込みをスキップしないのか」ということです。これも興味深い議論ですが、今のところはそうではありません。

4

1 に答える 1

0

クラスを自動的に再ロードできるようにするには、そのクラスがどのように構築されたかを知る必要があります。Rubyがいかに動的であるかを考えると、これは最も些細な場合にのみ簡単です。最終的な形になる前に大幅に拡張および変更されたクラスを持つことは十分に一般的です。クラスを再作成するために必要な手順を決定することは簡単ではなく、これらを追跡することはパフォーマンスの大きな低下になる可能性があります。

これの多くは、クラスがメソッド、インスタンス変数、クラス変数、定数、およびその他のモジュールとクラスのコレクションであるという事実に要約されます。C ++のような静的に型付けされた言語とは異なり、これらはいつでも、どこでも、理由を問わず宣言できます。クラスの状態は、単純に再生成できるものではありません。

Railsがクラスをリロードする方法は、問題のクラスを破棄してリロードできるようにするために、いくつかのトリックを実行することです。Railsは、クラスがリロードされていることを拡張機能に通知するためのいくつかのフックも提供する必要があります。そうしないと、多くの拡張機能が1回だけ読み込まれるため、クラスが再構築された後で操作をやり直すことができます。

要するに、表面的には些細なことのように見えることは、確かに非常にトリッキーであることがわかります。

于 2012-09-27T14:36:23.323 に答える