今日は前回の余談の続きから。ゆめみ iOS 研修課題 を眺めていたら不意に出てきた Equatable の適用判断周りで感覚的に難しく感じたところがあったので、みんなと意見交換してみたくなったのでそれを行ってみることにしますね。それらを見てから、他に気になるところはないか研修課題のコードを眺めてみたり、引き続き 循環参照 に見られる問題点のあたりを詳しく見ていく予定でいます。どうぞよろしくお願いしますね。
——————————————————————————————————— 熊谷さんのやさしい Swift 勉強会 #218
00:00 開始 00:18 前回の代入演算子についてのおさらい 02:22 代入演算子なのに代入しないのはアリ？ 03:40 驚きを与える API は推奨されない 05:36 やはり代入演算子っぽい 08:52 演算子の独自定義は慎重に 09:25 株式会社ゆめみ iOS 研修課題で気になったところ 10:28 Equatable の規模感 12:35 今回の Equatable は、テストを書きやすくする想定 13:46 理屈と実際とのバランス感の難しさ 15:34 Identifiable 16:14 本来 Hashable は等価比較性を持たない 17:23 理屈通りが正しいとは限らない 17:48 Equatable にしなかったときの最善の手は？ 20:59 ID での一致性判定は、今回は不適切 22:09 Codable で比較するのは強引な印象 22:37 独自のテスト関数を作る手はある 23:39 落としどころが難しい気がする 24:32 CaseIterable に持つ印象 25:01 全候補を列挙したいときに役立つ 26:48 allCases という名前は適切？ 29:06 汎用的なものは冗長になりがち ———————————————————————————————————