-
- いいね！4
Toshiyuki Takahashi
@tototoshi
@edvakf 2つめはFuture[Either[E,T]] 派というかモナドトランスフォーマー派だと思いました。この場合はEitherTじゃなくてOptionT使うと思います。
2015-03-26 10:30:37
Toshiyuki Takahashi
@tototoshi
@edvakf Scalaだとモナドトランスフォーマーそんな一般的ではないので普通の人は妥協して、もしくはそういうものとして最初の形にすると思います。最後のやつはIOとして想定しているのがDB以外もある気がしてなんとも言えないですが、よく見るパターンではないです。
2015-03-26 10:32:27
Toshiyuki Takahashi
@tototoshi
@edvakf あと別の話で、asyncなドライバー使ってない限りJDBCはブロックするので、Futureで返すよりはそのままOptionを返して、使う側でFuture.successfulでラップする、というのが良い気がします。
2015-03-26 10:35:23
Atsushi Takayama
@edvakf
@tototoshi Future でブロッキングコードをラップするという誘惑に駆られるかもしれないことに注意してください playframework.com/documentation/… というのが気になってます。Future.successfulするぐらいなら同期でいいのかなーと。
2015-03-26 12:27:52
Toshiyuki Takahashi
@tototoshi
@edvakf Futureでラップ、というのはFuture.applyを使ったものを言ってるんだと思います。Future.applyだと下手するとスレッドプール食いつぶすのでよくないです。
2015-03-26 12:33:38
Toshiyuki Takahashi
@tototoshi
@edvakf 一方Future.successfulはすでに計算で得られた値をFutureでくるむのに使うものなので特に心配いらないです。
2015-03-26 12:35:19
Atsushi Takayama
@edvakf
@tototoshi ほうほう。Future.successfulだとブロックするのは変わらないのですね。基本全部Future.successfulにしておいて、スループットが必要なところだけ本当の非同期にするのが良さそう。
2015-03-26 12:38:53
Kazuhiro Sera (瀬良)
@seratch_ja
前後関係がある Future 処理を一つの処理として抽出すればシンプルなケースではおかしなことにはならないと思うけど real world では横からはさみこみたくなる要件が継ぎ足されていくとつらくなる。
2015-03-26 21:07:59
Kazuhiro Sera (瀬良)
@seratch_ja
そういう要件は本当は同期処理でやるのがよいわけで、そこをあえて Future とかコールバック関数縛りでやらなければならない理由が何かを考える。リソース効率とか膨大な同時接続への耐久性を可読性を犠牲にしてでも得たいのかという。
2015-03-26 21:18:34
Toshiyuki Takahashi
@tototoshi
Playの場合Futureを多用するから同期処理もFuture型合わせゲームみたいになるときあるんだよなあ。
2015-03-26 21:20:25
Kazuhiro Sera (瀬良)
@seratch_ja
適当に作るとデバッグとか運用のトラブルシュートとか大変になるし、開発の難易度はそれなりに上がると思う。本当にトラフィック数や同時接続がすさまじい環境なら別だけど、そうでもない案件の場合だとそこを頑張るのって見合ってるのかなと。
2015-03-26 21:25:06
Atsushi Takayama
@edvakf
モナドトランスフォーマーは使っていくべきな気がしてきた。モナドじゃない値をモナドにするだけでも大変なのに、2階層とか考えたくもない
2015-03-27 05:52:55
しいたけ
@yuroyoro
Future についての私見 - seratch's weblog in Japanese seratch.hatenablog.jp/entry/2015/03/…
2015-03-27 19:45:24
しいたけ
@yuroyoro
お前らが、DBやファイルアクセスなど全ての処理を非同期コールバック意識して書かねばならない辛みと引き替えに得たいものは一体なんなのか? という話
2015-03-27 19:49:18
neuecc
@neuecc
async/await使えばいいとオモイマス。ScalaはScalaでこの辺の決定打/作法ないのね……。 / “Scala - DBから単一SELECTする関数の型をFuture[何]にすれば良いのか悩む - Qiita” htn.to/AT511f
2015-03-27 19:51:35
Toshiyuki Takahashi
@tototoshi
横からはさみこみたくなる要件が継ぎ足されていくとFutureがつらくなるってのはよくわかんないかも
2015-03-27 20:13:26
Kenji Yoshida
@xuwei_k
べつにasync/awaitであまり解決しないよなー？ C# 詳しくないからわからんけど。ただ「for式使え」と言われてるのと大差ない気がする twitter.com/neuecc/status/…
2015-03-27 20:30:17
Kazuhiro Sera (瀬良)
@seratch_ja
@tototoshi 分岐処理が増えるとやりくりする感じになるよねっていう感じですね。そこだけ同期にしちゃえば楽になれるけど、それが広がりすぎると何のための Future だったんだっけってなるし。
2015-03-27 20:31:36
Toshiyuki Takahashi
@tototoshi
@seratch_ja Future自体がめんどうというのはわかるんですけど、分岐が多いとめんどうというのがあまりピンとこないです。結局for式の中で普通に分岐書くだけのような？と思ったんですが。
2015-03-27 20:38:50
Kenji Yoshida
@xuwei_k
Futureは"未来を表す"とかいう変な厨二病的なものではなく、単なる純粋データ構造として表現もできて、それを理解できると色々非同期プログラミングに対する考え方が変わるかもしれない？ので、いいからFP in Scala(もしくはその翻訳本)を読みましょう
2015-03-27 20:40:24