問題タブ [reference-class]

クラス (または実際には S4/S3 クラス) を参照するための機能的なユーザー インターフェイスを提供することの概念的な意味を理解しようとしています。要するに、以下のようなコードを書くと、関数型のコードを書いているのと同じになるのではないかという懸念があります。

以下は単純な線形回帰クラスです。

オブジェクト指向のインターフェイスはあまりユーザー フレンドリーではないため、Martin Morgan のスライドのように、基になる参照クラスの機能的なユーザー インターフェイスを作成します。

現在、この機能的なインターフェースは、純粋に機能的なインターフェースと観察的に同等です

これが私の例が病理学的に単純なためかどうかを理解しようとしていますが、参照クラスを作成して関数インターフェイスにラップすることと、純粋に機能的なコードを作成することに意味があるかどうかはまだ疑問です。

詳細な例は非常に役立ちます。

簡素化された例では、フィールドPortfolio内の個々の資産値を保持する参照クラスのオブジェクトがありholdingsます。valueの個々の値を単純に合計することによって計算される追加のフィールドがありholdingsます。

スロットにデータを入力した直後に、スロットが計算さholdingsれることは明らかです。value

質問value:で直接呼び出されている場合にのみ、フィールドの遅延オンデマンド評価を実現するために定義を書き直す方法はPortfolio$value?

warning()動作しているように見えますが、参照クラスのメソッドでは無視されているstop()ようです。あれは、

利回りのみ:

これは意図的なものですか?もしそうなら、それはなぜですか? クラス メソッド内で警告を発生させるにはどうすればよいですか?

クラス ジェネレーターにクラス自体に別の名前を付けると (これには正当な理由があります)、問題が発生し始めました。

をもたらしました：

baz私ができるので、まだ方法は明らかに存在します：

ジェネレーター名を に変更すると、上記のエラーは発生しませんmyClass。

この動作が仕様によるものである場合、その理由は何ですか? これがバグである場合、どうすればこの問題を修正できますか? ジェネレーターとクラスの名前が異なることに起因する別の隠れた問題はありますか?

特定の参照クラス メソッドについて、それが継承されているかどうかを判断するにはどうすればよいですか? より一般的には、継承ツリーのどこまで上にいるのかを判断する方法は?

たとえば、私のセットアップが次の場合:

理想的には、私whosMethod()は私に次のようなものを与えたいです

これは、上記の例でclass(.self)常に返されるとは明らかに異なることに注意してください。"B"

動機 - カスタム イベント

カスタムイベントなど、メソッド以外の他のものに対して継承のような動作が必要です。私のメソッドはraise(someEvent)、インスタンス化中にイベントハンドラーを渡してそれらのイベントを処理する場合があります。

ここで、子クラスが、親クラスによって既に定義されているイベント ハンドラーを定義する場合、どのイベント ハンドラーをオーバーライドする必要があるかを知る必要があります。特に、 がmethodA()登録さhandlerA()れsomeEvent、methodB()子クラスが同じイベントに登録handlerB()する場合、登録しようとすると、すでに登録されている場合はそれをオーバーライドしないように、親メソッドにいることを知る必要があります。handlerA()methodA()handlerB()

callSuper()また、メソッドで使用できるように、子イベント ハンドラから親イベント ハンドラを呼び出せると便利です。

ジェネレーター オブジェクトを拡張したいのですが、このテーマに関するすべての R ヘルプ ファイルは次のとおりです。

refGeneratorSlot参照クラス生成機能をサブクラスで拡張したい場合は、 ではなくをサブクラス化して行う必要があることに注意してください refObjectGenerator。

わかりましたが、実際にこれを行うにはどうすればよいですか? だから私は試しました：

しかし今何？を使用するクラス定義と組み合わせてこれを実際に使用するにはどうすればよいsetRefClass()ですか?

R 参照クラスに関して、デフォルトの$initialize()コンストラクターをオーバーライドすると、フィールドを初期化するためのより良い方法と見なされ$initFields()ます$callSuper()。

私はいくつかの長所/短所を検討しました：

• のデフォルトの動作が$initialize()R の将来のバージョンで変更/拡張された場合、$callSuper()コードを追加/書き直さなくても、それらの変更が反映されます。

• $callSuper()1 回の呼び出しで 2 回呼び出すことを妨げるものは何もありません$initialize()。そのようなシナリオで何が起こるかは公式に文書化/明確に定義されていますか?

たとえば、次のパッケージが呼び出されていて、TestクラスをエクスポートしたいとしますA。

Aただし、ビルドしてロードした後、のジェネレーターを使用すると、次のエラーが発生します。

NAMESPACEファイルの内容に問題がないことを確認しました。

それで、何がうまくいかないのですか？クラス ジェネレータがエクスポートされないのはなぜですか?