Collectionsについて話してきました。4.5からReadOnly系が入ってきて、話が更新されているもの)ので、資料として役に立つのではないかと思います。Framework前半部分ですが、これのジューヨーなところはILinqable<T>、じゃなくて(スライド資料では出てないのでナンノコッチャですが)、ReadOnly系の取り扱いですね。MutableとReadOnlyが枝分かれしている理由とか対処方法とか、が伝えたかった点です。いやあ、コレクション作る時は両方実装しよう!とかしょうもないですねえ、shoganaiのですねぇ......。IEnumerable<T>とIReadOnlyCollection<T>の差異は実体化されていない「可能性がある」かどうか。メソッドの引数などで内部で実体化されてるのを前提にほげもげしたい場合は、IReadOnlyCollection<T>を受け取るほうが望ましいといえば望ましいのですが、汎用的にIEnumerableのままで......という場合は、以下のようなメソッドを用意しとくといいでしょう。sourceが遅延状態の場合、実体化して返し、既に実体化されている場合は何もせずそれ自身を返します。name="source">対象のシーケンス。name="nullToEmpty">trueの場合、sourceがnull時は空シーケンスを返します。falseの場合はArgumentNullExceptionを吐きます。source.ToArray();}こんなのを作って、冒頭で呼べば、二度読みなどもOKに。あとは好きに書けばいいのではないでせうか}どうでしょ。二度読みなら列挙したらキャッシュして、再度読む時はそっから読んでくれればいいのに!というリクエストあるかと思います。それは一般的にはメモ化(Memoization)といいます。いうわけで、シーケンスに実装してみましょう。Console.WriteLine(item);}といった感じ。Materializeより合理的といえば合理的だし、そうでないといえばそうでない感じです。私はMaterializeのほうが好み。いうのもMemoizeは完了していないEnumeratorを保持しなければいけない関係上、Disposeの扱いがビミョーなんですよ、そこが結構引っかかるので。あと、IEnumerable<T>ですが、スレッドセーフではない。IEnumerable<T>にはスレッドセーフの保証は実はない。いうのを逆手に取ってる(まぁ、それはあんまりなので気になる人はlockかけたりしましょう)。ちなみにReadOnlyCollectionだってラップ元のシーケンスが変更されたらスレッドセーフじゃない。Collections。いう話につながったりつながらなかったり。timeを読めば、なんなのかっては分かるのではかと。その上で私が今回で割と酸っぱく言いたかったのは、ReadOnly「ではない」ってことです。結論はアリキタリに使い分けよう、という話でした。セッション後の話とかTwitterで、バージョニングされたコレクションって捉えるといいんじゃないの?と意見頂いたのですが、なるほどしっくりきそうです。LINQ勉強会で発表する予定なので、関西圏の人は是非是非どうぞ。Objects」を予定しています。Diveの部分は全部OK、といった内容にするつもりです。初心者向けってこともないので、完全に上級者がターゲットで。voidを避けるべき100億の理由2013-10-10だいぶ前から時間経ってしまいましたが、非同期の落とし穴シリーズPart3。Taskで書くべき、というのは非同期のベストプラクティスで散々言われていることなのですけれど、理由としては、まず、voidだと、終了を待てないから。voidだと、その中の処理が軽かろうと重かろうと、終了を感知できない。例外が発生しても分からない。これがTaskになっていれば、awaitで終了待ちできる。例外を受け取ることができる。Task.WhenAllで複数同時に走らせたのを待つことができる。Taskで書かない理由のほうがない。voidが存在するかというと、イベントがvoidだから。button_clickとか非同期対応させるにはvoidしかない。