Explore CoroutineScope

Transcript

1. Explore CoroutineScope Kotlinコルーチンにおける「型安全 × 柔軟性」の設計
2. About Me 名前: tomo 所属: 株式会社 Voicy プロダクトエンジニア X: @tomoEng11 好きな言語: Swift 最近Kotlinの勉強を始めました！
3. CoroutineScopeとは 非同期処理 (コルーチン )を親子関係でまとめて、ライフサイクルとキャンセルを管理する起点
4. CoroutineScopeの定義を詳しくみる 個人的な疑問 • CoroutineContextって何？ • Jobを足してる？ • context[Job]って何？
5. CoroutineContext コルーチンの「設定情報（プロパティ）の集合体」 クラス名 主な役割 CoroutineDispatcher スレッドの割り当て Job キャンセルや状態の追跡 CoroutineExceptionHandler 未キャッチ例外のハンドリング CoroutineName コルーチンに名前を付与
6. CoroutineContextの構成
7. CoroutineContext.Element • Elementに対応するKeyが存在する • ElementもCoroutineContextになっている
8. だから Contextの操作がシンプルにできる
9. 個人的な疑問 • ✅CoroutineContextって何？ • ✅Jobを足してる？ • context[Job]って何？
10. context[Job]の仕組み 本来はKeyを指定する必要があるのに、なんで型を指定しただけで取り出せるんだ？
11. CoroutineContextのgetメソッド 引数にKey<E>を要求している
12. Jobの定義を⾒てみる companion objectとして、Keyが定義されているから型名からアクセスできる
13. CoroutineContext
14. CoroutineContext minusKeyの引数がKey<*>になってるのはなんで？
15. minuskeyはなぜKey<*>なのか？ Key<CoroutineContext.Element>でもよくない？
16. minuskeyとgetの違い メソッド 戻り値 Elementへの関心 get E? あり minusKey CoroutineContext なし
17. なぜKey<Element>ではダメか？ Jobなどは、CoroutineContext.Elementのサブクラスだから Key<Job> != Key<CoroutineContext.Element> Keyのジェネリクスになった時点で、同一ではなくなる (invariant)
18. outにしてみたらどうか？ 型とKeyの対応が崩れてしまう Key 期待する型 Key<Job> Job Key<CoroutineName> CoroutineName outにするとgetで正しい型が返せなくなる
19. まとめ • CoroutineContext は複数の要素を持つMap的構造 • Key はcompanion objectで定義されていて、型との対応を表現 • get は型安全に取得 → Key<E> • minusKey は削除のみ → Key<*> • invariant を活かした設計で型安全を保証 KotlinのAPI設計めっちゃ勉強になる！！
20. ご清聴ありがとうございました