『プロトコル拡張を、それに準拠する将来の型で制約して、既定の実装を添えよう』という話を発端にした考察
- es_kumagai
- 1905
- 7
- 2
- 0
これを踏まえて、そもそもの対処策を考えるとしたら、やっぱりミックスインにこだわらないで共通関数化かな? それか AnyCellType とかを作って、その型に付属型で CellType を持たせて、AnyCellType を拡張すると、どうなるんだろう、とか?
2016-03-07 00:15:28とりあえず、ひとつのプロトコルを軸に Self で型を指定するのは悪夢を生みそうな予感がするので、別の手立てに移っておくのが無難な気がした。
2016-03-07 00:16:53あれ? そういえば少し前に Protocol だけの(異様に見える)例で挙げたときはイメージ通りの動きで衝突しなかったような…? というのを思い出したんですけど、よく見たらその検証は A0 ではなく A1 と A2 に入れて扱ってたからか。 #swift
2016-03-07 11:45:35これね。最後に昨日にずっとお話ししていたのと同じ、A0 として扱うコードを追加しました。これだと昨日の結論の通り、衝突してくれました。よかった🙂 gist.github.com/b66054ab1ce654… #swift pic.twitter.com/hOicAbGQbh
2016-03-07 11:48:45なんとなく感覚が掴めてきた気がする。大事なところは A0 への拡張だから、そこに2つが存在していて。そして、プロトコルをそのままコンクリートな型として A1 と A2 で扱う分には、目で制約条件を読むからにも、普通に衝突することもなく扱えて自然な感じがしますね。 #swift
2016-03-07 11:53:11そして P0 として扱った時に、コンパイラが混乱し出す気持ちもわかる。プロトコルの世界観ではオーバーライドみたいなのがないので A0 が起点になるわけですけど、ここで条件を探るにはインスタンスの型が何か判断しないといけない、ということになりそう。 #swift
2016-03-07 11:57:08つまり dynamicType 的な、とはいえビルド時にエラーになるみたいなので、静的と動的の中間(何方かと言えば静的)みたいな層での判定になっていそうな気がするけれど、とにかく起点が A0 なので、目で条件判定を見てみても「どっちなのさ?」という気持ちになれる。 #swift
2016-03-07 12:02:20ここで、自分はこれまで大変な勘違いをしていたかもしれないことに気がついた気がする。プロトコル拡張って「条件に合わない場合は実装しない」ではなくて「書いた分だけ、常に存在」してますね、きっと。プロトコルの世界観でのお話。よく考えたら当たり前のことかもしれない。 #swift
2016-03-07 12:04:46条件が合えば実装される、というのはオブジェクトの世界観だけのお話、直前のツイートと合わせてそう捉えると、なんか世界観がはっきりしてくる心地がする。そうすると「プロトコル拡張はミックスインとは限らないよ」そういうこともだいぶ自信を持って言えるようになってきそうな勢い。 #swift
2016-03-07 12:07:34後半のコードを実際に試すと実行時(型の世界)での判定になるのでちゃんと動いてしまうけれど、ビルド時の動作もこんな感じなのかもしれない。 gist.github.com/2a77b371207001… #swift pic.twitter.com/KsDerkVIAz
2016-03-07 12:23:25『幾つか該当候補があるけど、どれに該当するのかよく分からないね』みたいな動き。A0 にガッツリ着目している時のお話です。 #swift
2016-03-07 12:25:44ああ、さらにわかった。ここに昨日の where Self : Any の話、挿入できますね。どういう順番で挿入するかは知らないですけど、感覚的にはたぶん最後になるはず。 gist.github.com/09f54201c73fd4… #swift pic.twitter.com/P1fT3aMmLi
2016-03-07 12:29:34ちなみに Self : Any はないのと同じなので、先ほどの例の default に書くのが近そうですけど。もっともこのコードは単なる説明用のものなので、あまり気にしないで欲しいところですけど。 #swift
2016-03-07 12:31:13まあ、わかった。とにかくこれまで悩んだ動きも、さっきのコードみたいなところまで世界観を掘り下げてみると、自然な動きに見えてくるかもしれませんね。 #swift
2016-03-07 12:32:26と、いうわけで完結した感 ( ´ △ ` ) 明日また目覚めたら次の穴が見つかったりするかもわかりませんけど。 #swift
2016-03-07 12:33:29確かにそうね。このメソッドは注入するよーしないよーって、プロトコルにしてはちょっと動きが具体的すぎるかも知れない。今回たどり着いたイメージの方が、単に情景を映し出してるみたいな感じで、なんとなくプロトコルの性にあってる気もしなくもない。 #swift
2016-03-07 12:37:48enum使って採用する型をパターン分けしたり出来るかも?router作る感じで twitter.com/es_kumagai/sta…
2016-03-07 17:12:17そして、似た構造をプロトコルの世界だけで組み立てたもの。クラスのと比べ始めてしまうと混乱するけど、見て欲しいのは単に extension 行の異様な雰囲気。 gist.github.com/6f4c4e6d8209f3… #swift pic.twitter.com/6yLnbfIq2Y
2016-03-06 13:51:38おお、なるほど。そもそも A0 で下流の A1 や A2 に依存するコードを書ける場面なのなら、確かに無条件 extension で、メソッド内で採用する方を自分でコーディングすることだって実現性の面では確かに可能な気がしますね。 twitter.com/ktanaka117/sta…
2016-03-07 17:21:00@niwatako @sinsoku_listy @eduraaa 土曜日のお話、理屈が整理できました。土曜日以降は @edurraa さんと意見合わせしてないですけど、たぶんこれで大丈夫なはず。後の理想はいったん実装組に任せます! togetter.com/li/947075
2016-03-07 18:28:43@niwatako @sinsoku_listy @eduraaa @edurraa とりあえず実装の観点で主旨をまとめると『あるプロトコルを Self 縛りで拡張した時、そのプロトコルを型として使うと地獄を見ることになりそう』です。あと理屈の観点でバグッぽさは感じなかったです。
2016-03-07 18:33:20@es_kumagai @sinsoku_listy @eduraaa @edurraa 地獄...!そんな扉を開いてしまっていたのか
2016-03-07 18:35:15@niwatako @sinsoku_listy @eduraaa かなり遠回りしているので、ところどころを参考にしつつ、何か良い切り抜け方を見つけてもらえたら幸いです🙂
2016-03-07 18:36:14@niwatako @sinsoku_listy @eduraaa @edurraa それでも最後に希望が出てくる、かもしれない😏
2016-03-07 18:37:05混乱してきたので実験してみたのだけど、次第に Self が何者なのかわからなくなってきた\(^o^)/ gist.github.com/06231a554def54… #swift pic.twitter.com/IA6tm3boLW
2016-03-07 23:01:13