りりろじさんのfujitaskに関する感想

病気の美少女 @lyrical_logical

今更読んだ。応募した社の人間の記事に文句つけるのもなんだけれど、内輪で天才～とかいうのは別にいいと思うんですがそれを public な場でやっちゃったり、発明とか言っちゃうのは寒くないですか…というか別に難しくないし普通やん… qiita.com/pab_tech/items…

病気の美少女 @lyrical_logical

まず権限について。たまたま Read, Write, ReadWrite という権限の関係が半順序になってるので継承関係で表せば素直な型制約で表現可能ですがそうでなかったとしても implicit を使ったメタプログラミングで制的に制約を記述することはできる。まあ普通だと思う。

病気の美少女 @lyrical_logical

あと診察待ちの間で考えていたけれど、qiita の件は、トランザクションオブジェクトと権限の型は分けたほうが順当なのではないかと思った。権限は phantom type で扱う。でないとトランザクションオブジェクトの詳細実装が複数ある場合に困らないかな。困らないか。頭が回らない…

病気の美少女 @lyrical_logical

まあギョームしてて同僚とかがああいうのさくっと書いてくれたら「おっがんばっとるやんけ～いいぞいいぞ～」って思うしえらいぞ～って思うけど外部に向けて天才とか、仮に自分が言われる立場だったらすごい嫌でどっちかというとその話がしたかったのにオタクだから気づいたらコードに意識が向く

病気の美少女 @lyrical_logical

することないので真面目に読み直してたけど、解説間違ってたり、解説意味不明だったりしてませんかこれ。 qiita.com/pab_tech/items…

病気の美少女 @lyrical_logical

github にあがってるコードのコメントも記事と同じでおかしいしドワ社の scala 書き各位大丈夫ですか。

病気の美少女 @lyrical_logical

あんどろこさんからだと面倒だな… "変位指定によりResourceの型は両方のTaskのResourceの共通のサブクラスの型に" 変位指定ではなく型制約（type parameter に対する upper bound）、Resource じゃなくて Extended の方では

病気の美少女 @lyrical_logical

ReadWrite と Read 合成するときに f が型チェック通るように variance が contravariant にしてあるのであって variance で共通のサブクラス（これも適切な表現ではない）とってきてるわけではないのでは、といいたかった