- HTTPはそもそもstatelessだ
- sessionとかをホゲホゲしてstateを持ち込むけど、そっちを基準にして考えるよりstatelessを基準にして考えた方がいいと思う
- ここからはWebアプリのことなので、プロトコルから演繹するものかどうかはアレだけど続ける
- HTTPは本来statelessだから、副作用を持たない（または副作用が推奨されない）関数型言語が向いてるぜ！っていうのはいきすぎ
- その逆でもないけど、継続を使ってアレアレするぜ！ってのもアレ
- プロセス内にずーっと持ってるものと、リクエストごとにnewするもの（必ずしもオブジェクトじゃなくてもいいけど）が頭の中 / 設計上で区別されていて、両者が然るべきカタチで使い分けられていれば十分な気がする
- 前者であるべきものが後者になっていたり、後者に入るべきものが前者に入っていたりすると悲しい
- たとえば前者の内容を、リクエストごとに書き換える必要があるとか（前者はほぼimmutableでよいものになると思う）
- 分かりやすい(?)前者は、DBのslave/master、shardを解決するクラスのインスタンスとか
- 分かりやすい後者は、Context object（あるなら）とか、Request objectとか
- 性能とか気にならないなら、全部後者だと余計なこと考えなくてもいい気がする（現実的には厳しいとおもう）
- Request的なものはimmutableでいい
- Contextにstateが多すぎると破滅するけど、ないと多分不便
- Response的なものはmutableでないと不便
1〜2年後くらいに自分でこれを見て、「青いなあ〜」と思えることを希望
※追記 もっと早いほうがいい
