blog
blog copied to clipboard
haskell-jp
Topic Request: 普通のレコード型を定義するときのベストプラクティス
Slackでの https://haskell.jp/slack-log/html/C4M4TT8JJ/64.html#message-1577159731.008800 あたりの議論から:
@as_capabl
なるほど、この辺ふまえて2019年時点で、普通のレコード型を定義する場合のベストプラクティス、みたいな奴をだれかがまとめると良いかもしれませんね
とりあえず
- rioのベストプラクティス をベースに
-
RecordWildCardsはrio的には非推奨ですが有効にして -
DuplicateRecordFieldsOverloadedLabelsを有効にして - どこかのパッケージのIsLabelインスタンスを使って
#member等をgetterとして使えるようにする - rioのReaderTパターンで使う
Hasインスタンスを定義する
みたいなストーリーになると思っています。
どこかのパッケージのIsLabelインスタンスを使って #member 等をgetterとして使えるようにする
generic-lensがいいでしょうね。Has のインスタンスも自分で定義する必要はないはず。
Has のインスタンスも自分で定義する必要はないはず。
すいません、ものすごく飛躍しました。rioのHasインスタンスは、上記rioベストプラクティスの When defining Has-style typeclasses から始まる節で触れられているやつです。
普通のlensを使う時は makeClassy をよく使うので、OverloadedLabelsに移行する時はどうしようかと悩んでいる所です。
いや、それはわかるんですが、わざわざ手で定義しなくても十分 http://hackage.haskell.org/package/generic-lens-1.2.0.1/docs/Data-Generics-Product-Fields.html#t:HasField で代用できるのではないかなぁと思いまして。
なるほど、自分の書くコード間だったら、それでいけそうです。 ただ既にrio準拠で作られているライブラリを使う場合は、手書きが必要になってしまうという問題があります。
このボイラープレート嫌だよね、とは本家の方でも言われているみたいです https://github.com/commercialhaskell/rio/issues/113
いろいろ調べてみたのですが、generic-lensのヘッダに "Use at your own risk." などと書かれているのを鑑みるに、まだベストプラクティスと呼ぶには成熟していないと考えた方がいいと思います。
https://hackage.haskell.org/package/generic-lens-1.2.0.1/docs/Data-Generics-Labels.html
とはいえOverloadedLabelsによるレコード操作は今後主流になっていくであろう機能なので、タイトルを変更して「OverloadLabelsとgeneric-lensでストレスフリーなレコード型を」という記事にするのはどうでしょう（せっかくなので執筆してみたい）
いいですね！
個人的には、多少タイプ数が多くても field @name などと書くつもりだったので、 Data.Generics.Labels については想定していませんでした。
#name でアクセスできるようにもしてくれてるんですね。
「Use at your own risk.」なのはgeneric-lens全体ではなく、このモジュールが IsLabel のorphanなインスタンスを定義してしまっているからではないかと。
タイトルを変更して「OverloadLabelsとgeneric-lensでストレスフリーなレコード型を」という記事にするのはどうでしょう（せっかくなので執筆してみたい）
ぜひぜひ！ 👍
