問題タブ [yield]

次のコードがあるとします（質問の範囲を制限するためにコンテキストを絞り込みました）

私はそれらをこのようなものに書き直したいと思います（もちろんコンパイルされません

重要な点は、最初のスニペットで2つのforeach列挙子が生成されることです。これは、遅延読み込み機能を失うことなくlinqで実行する方法がわかりません。

そこで、私は同僚とファイバーについてチャットしていて、ファイバーAPIを使用したC＃でのコルーチンの実装について説明している2003年の論文を発表しました。

このホワイトペーパーでの実装はYield.NET1.1用であったため、.NET2.0yield returnに登場した構文よりも前のものです。

一見すると、ここでの実装は潜在的に高速であり、複数のCPU間でかなりうまく拡張できるように見えます。

誰かがそれを使用しましたか？

私は、Silverlightプログラムをリファクタリングして、既存のビジネスロジックの一部をWCFサービスから消費するように書いています。そうすることで、Silverlight 3の制限に遭遇しました。これは、WCFサービスへの非同期呼び出しのみを許可し、長時間実行または応答しないサービス呼び出しがUIスレッドをブロックするケースを回避します（SLには、WCFサービスを呼び出すための興味深いキューイングモデルがあります） UIスレッド上）。

結果として、かつては簡単だったものを書くことは、急速に複雑になりつつあります（私の質問の最後にあるコード例を参照してください）。

理想的には、実装を簡素化するためにコルーチンを使用しますが、残念ながら、C＃は現在、母国語機能としてコルーチンをサポートしていません。ただし、C＃には、yield return構文を使用するジェネレーター（イテレーター）の概念があります。私のアイデアは、yieldキーワードを再利用して、同じロジックの単純なコルーチンモデルを構築できるようにすることです。

ただし、（SilverlightとWCFの経験が比較的少ないことを考えると）予期しない隠れた（技術的な）落とし穴があるのではないかと心配しているため、これを行うのは気が進まない。また、実装メカニズムが将来の開発者にとって明確ではなく、将来のコードの維持または拡張の取り組みを簡素化するのではなく、妨げる可能性があることも心配しています。ステートマシンを構築するためのイテレータの転用に関するこの質問をSOで見ました。「yield」キーワードを使用してステートマシンを実装します。これは私が行っていることとまったく同じではありませんが、一時停止します。

ただし、サービスコールの複雑さを隠し、このタイプの変更における作業と欠陥の潜在的なリスクを管理するために、何かを行う必要があります。私は、この問題を解決するために使用できる他のアイデアやアプローチを受け入れています。

コードの元の非WCFバージョンは次のようになります。

再ファクタリングされたWCFバージョンは、かなり複雑になります（例外処理や事前/事後条件テストがなくても）。

上記のコードは、例外処理、nullityチェック、および本番コードで必要となるその他のプラクティスを省略しているという点で、明らかに単純化されています。それでも、Silverlightの非同期WCFプログラミングモデルで発生し始める複雑さの急速な増加を示していると思います。元の実装（サービスレイヤーを使用せず、SLクライアントにロジックを組み込んだもの）のリファクタリングは、急速に困難な作業になりそうです。そして、かなりエラーが発生しやすいものです。

コルーチンバージョンのコードは次のようになります（私はまだこれをテストしていません）：

上記のコードには、改善が必要なあらゆる種類のものがあります。ただし、基本的な前提は、継続パターンを除外し（例外処理とさまざまなチェックのためのインターセプトポイントを作成する）、各ステップが実行されるとき（基本的には最後の非同期WCF呼び出しが完了するとき）にWCFのイベントベースの非同期モデルを駆動できるようにすることです。一見すると、これはより多くのコードのように見えますが、言及する価値がPerformSteps()ありNextStep()、再利用可能ですが、ButtonClickCoRoutine()実装サイトごとに変更されるのはの実装のみです。

このモデルが好きかどうかは完全にはわかりません。また、このモデルを実装するためのより簡単な方法があったとしても驚かないでしょう。しかし、「interwebs」やMSDN、またはその他の場所で1つを見つけることができませんでした。助けてくれてありがとう。

Pythonスレッドに譲歩するように指示したいので、CPUを不必要に占有しないようにします。Javaでは、関数を使用してそれを行うことができますThread.yield()。Pythonには似たようなものはないと思うので、time.sleep(t)whereを使用していt = 0.00001ます。t=0効果がないようです。

Pythonのスレッドモデルについて正しく理解していないことがあるかもしれません。そのため、が欠落している理由がありthread.yield()ます。誰かが私にこれを明確にすることができますか？ありがとう！

PS：これはJavaのドキュメントがThread.yield()言っていることです：

現在実行中のスレッドオブジェクトを一時的に一時停止し、他のスレッドの実行を許可します。

django.templateに次のコードがあります。

私が混乱している部分は以下のとおりです。この__iter__方法はどのように機能しますか？対応する方法が見つかりませんnext。

これは私が実装する方法を知っている唯一の方法です__iter__：

私の英語はあまり上手ではないので、あなたの答えでは、テキストではなくコード例を使用するようにしてください。

チュートリアル (Professional ASP.NET MVC - Nerd Dinner) に取り組んでいると、次のコード スニペットに出会いました。

を読みましたがyield、私の理解はまだ少しぼんやりしていると思います。それがしているように見えるのは、絶対に必要な場合を除き、実際に循環を行うことなく、コレクション内のアイテムを循環できるオブジェクトを作成することです。

ただし、この例は私には少し奇妙です。私が考えていることはRuleViolation、プログラマーがコレクション内の特定の項目を実際に要求するか、for eachまたは のような LINQ 拡張メソッドを使用するまで、インスタンスの作成を遅らせること.ElementAt(2)です。

ただし、これ以外にもいくつか質問があります。

1. ifステートメントの条件部分はいつ評価されますか? いつGetRuleViolations()呼び出されるか、または列挙型が実際に反復されるのはいつですか? 言い換えれば、私が呼び出してから実際にそれを反復しようとするまでの間に から の値が変化した場合、作成さTitleれるかどうか？nullReally Geeky DinnerGetRuleViolations()RuleViolation("Title required", "Title")

2. なぜyield break;必要なのですか？ここで実際に何をしているのですか？

3. Titlenull または空であるとしましょう。呼び出しGetRuleViolations()てから、結果の列挙型を 2 回続けて反復すると、何回new RuleViolation("Title required", "Title")呼び出されますか?

クラスと、このクラスを使用してリスト内のリストを提供する一連の IEnumerables があります。(詳細については、この質問の回答を参照してください。)

コードは次のとおりです。

そしてクラス：

この結果を ListBox の ItemsSource に設定しました

このリスト ボックスのイベントをキャッチしようとすると、問題が発生します。

デバッグ中に e.AddedItems[0] を調べると、そのタイプは EnumerateColumns であると表示されます。

その型にキャストしようとすると、Visual Studio は (当然のことながら) EnumerateColumns はメソッドですが、型のように使用されると言っています。

では、これをタイプ別に参照して、foreach ループを実行し、その中のものを取得するにはどうすればよいでしょうか?

これは、答えに基づいて更新されたコードです。

以下のコードは機能しますが、yield を使用するか、アルゴリズムを変更してコードを最適化したいです。

Java自体には直接同等のものがないことは知っていますが、おそらくサードパーティですか？

本当に便利です。現在、ツリー内のすべてのノードを生成する反復子を実装したいと考えています。これは、yield を使用した約 5 行のコードです。

Python では、ジェネレーター式を使用してジェネレーター オブジェクトを作成する場合と、 yieldステートメントを使用する場合に違いはありますか?

yield の使用:

ジェネレーター式の使用:

どちらの関数も、(0,0)、(0,1) などのタプルを生成するジェネレーター オブジェクトを返します。

どちらかの利点はありますか？考え？