1

私はFuture<T>値を非同期的に取得することをカプセル化する汎用クラスを作成していますが、Web 上のほとんどの既存の実装には次のような契約があることに気付きました。

public class Future<T>
{
    public Future(Func<T> func); // kicks off the async operation
    public T Value { get; } // gets the value and blocks if the async operation isn't done
}

これにより、すぐに実装に Completed イベントを追加したくなります。これにより、値を非同期で取得し、いつ完了したかを知りたいときに値をポーリングする必要がなくなります。Parallel Programming ライブラリがこのように先物を実装していることに気付きましたが、なぜ多くの実装にこのイベントがないのか興味がありました。何か不足していますか？Futures には Completed イベントが必要ですか? それとも、あなたの文脈に依存しているだけですか？

4

2 に答える 2

3

このようなものをイベントとして、あるいは継続への委任を受け入れる方法として持つことは、汎用的には有用だと思いますFuture<T>。特定の目的のためだけに構築している場合は、必要ない場合があります。

また、ネット上の例は多くの場合、本番品質のコードではなく、実際には必要ではないが、このような便利な機能を見逃している可能性があることに注意してください。

この機能はすでにフレームワークにの形式で含まれているため、作業はまったく必要ない場合があることに注意してくださいTask<T>。

于 2011-06-27T20:49:52.807 に答える
2

そうすることで、先物の概念が幾分濁ると思います。私の意見では、future の全体的なポイントは、シーケンシャル スタイルのコードで非同期に計算される値を使用できるようにすることです。より明白な非同期スタイルが必要な場合は、それが継続渡しの目的です。

とは言っても、私が高慢になりがちな不満ではありません。.NET の Task クラスは両方のスタイルのサポートを組み合わせており、これまでのところ完全に満足しています。ただし、私は 2 つのスタイルを別々に保つようにしています。Task を強制する予定がある場合は、それに継続を割り当てることは避けたいと思います。逆の場合も同様です。

于 2011-06-27T22:57:02.863 に答える