概要‎ > ‎

AppVar仕様変更アンケート

AppVarがIDisposableを実装するのをやめ、代用にReleaseメソッドを公開する。
(過去バージョンと互換性が一部なくなります。)

やったほうがいい。  or    やる価値なし。


AppVarというクラスがあります。
これは、操作対象プロセスの内部インスタンスのプロキシとなるクラスです。
図にすると、こんな感じです。


最近ではdynamicを使うことを推奨しているので、あまり見かけませんが、
dynamicで使うインスタンスの奥底にもこれがいます。
2.0で書く場合はこれが全面に出てきます。

もちろん、このクラスで操作している間に
Aプロセスでガベコレで消されるとまずいので
Bプロセスで使っている間はガベコレ対象から外れています。
そして、A、Bの両方で使わなくなるとガベコレ対象となります。

ここでBのプロセスで使わなくなるというタイミングなのですが、以下3パターンあります。
①BプロセスのWindowsAppFriend(Aプロセスにアタッチしたクラス)がDisposeされる。
②BプロセスでAppVarがガベコレされる。
③BプロセスでAppVarに対してDisposeを呼ぶ。

通常は①か②のタイミングで良いのですが、例外的に大きなメモリのインスタンスを保持した場合は
使い終わったら、即座に解放したいことになります。
これは、Bプロセスのガベージコレクタは、AppVarの指しているメモリの大きさとかわからないからです。
なので③を用意しました。


しかし、AppVarは、いたるところで使うので③を常に呼ぶようにすると、面倒なコードになるので、
特殊なケース以外では呼んでほしくないのです。
(①でまとめて消すか、GCクラスでGCを促進させるなどで代用してほしいのです。)

なのですが、IDisposableを実装してしまったため、これを見た人は
必要以上にDisposeを呼ぶ欲求に駆られてしまうのです。

ここで対応として、表題の仕様変更を入れようかと考えています。

その他考慮点として
・過去バージョンと互換性がなくなる。
・次期バージョンはメジャーバージョンアップにする。
    →互換性が多少なくなっても許してもらえるかも。
     ここを逃すとしばらく、変更するチャンスはなくなる。
・dynamicを使う場合はそれほど気にならない。
    →だったら、仕様変更しなくていいのでは?
・今のままの仕様でも、DisposeしなくてもFxCopには怒られない。
→これはAppVarはnewで生成することがなく、メソッドで取得するためです。
     メソッドで取得したIDisposableなインスタンスは破棄すべきか判断できないので。
     実験の結果、メソッドでもCreateから始まるメソッドの場合は生成したと判断され、怒られました。
・今の仕様でもドキュメントには、その旨書いている。
    インテリセンスや、定義ジャンプで見れるドキュメントでも見れます。

メリット、デメリットあるので迷い中です。
よろしければ、ご意見お願いしいます。

Friendly*codeer.co.jp(*は@に変更お願いします。)