These are chat archives for scalikejdbc/ja

11th
May 2016
Manabu Nakamura
@gakuzzzz
May 11 2016 04:17
型クラスのインスタンス探す時、だいたい型から探すからインスタンス名を型名にしちゃったんですが、https://github.com/gakuzzzz/scalikejdbc/blob/274100f0cc57967395c6eab5b6cc483a03875391/scalikejdbc-core/src/main/scala/scalikejdbc/Binders.scala#L133 TypeBinder とかは ResultSet のメソッド名ベースでの名前なんですよね。
これそっちに合わせた方がいいですかね?
エイリアスとして両方定義しておく?
asciiStream とかもあるからややこしい……
Kazuhiro Sera
@seratch
May 11 2016 04:21
binaryStream と asciiStream は選択できた方がよさそうな予感... ですかねぇ。
内部的に get|setBinaryStream してるんでそっちの名前がよいと思います。
Manabu Nakamura
@gakuzzzz
May 11 2016 04:23
探す時に見つけられなそうな気もしてるんですよね……
ユーザが選択可能にすると asciiStream とかも public にした方が良い感じですかね
Kazuhiro Sera
@seratch
May 11 2016 04:27
そんな気がします。探すときは統一されてれば大丈夫じゃないかなと。
Manabu Nakamura
@gakuzzzz
May 11 2016 04:28
うす、その方向で push してみました。
Kazuhiro Sera
@seratch
May 11 2016 04:32
これはよい PR
Manabu Nakamura
@gakuzzzz
May 11 2016 04:32
あざますあざます
kenji yoshida
@xuwei-k
May 11 2016 05:07
ボイラプレート確かに多少減ってるけど、まだボイラプレート発生するので、なんかもうちょっとうまくやるべき方法模索するべきな気もするけど、うーん・・・
Manabu Nakamura
@gakuzzzz
May 11 2016 05:10
要素1個の case class ならマクロで生成とかは可能かもですね
kenji yoshida
@xuwei-k
May 11 2016 05:12
というか、要素2個以上のclassで定義する場合ってほぼない?(よくわかってない)
Manabu Nakamura
@gakuzzzz
May 11 2016 05:13
場合によってはありうる気も
現実的にめったに無いかな……
一つのカラムにカンマ区切りとかで複数の属性保存してるとかそういう類だと有り得たりしますね。(SQLアンチパターン!)
kenji yoshida
@xuwei-k
May 11 2016 05:16
もし2つ以上があるなら、jsonのエンコーダー/デコーダーとかでのパターンと同じで、argonautのこれ(事前に22までコード生成) を思い出した(これをやるべきか、マクロでやるべきかは悩ましいところだが?) https://github.com/argonaut-io/argonaut/blob/v6.2-M1/project/Boilerplate.scala https://oss.sonatype.org/service/local/repositories/releases/archive/io/argonaut/argonaut_2.11/6.2-M1/argonaut_2.11-6.2-M1-javadoc.jar/!/index.html#argonaut.GeneratedEncodeJsons
Manabu Nakamura
@gakuzzzz
May 11 2016 05:18
まぁそういうケースだと区切り文字とか入れなきゃいけないから自動生成にできないし、無視でもいいかも
kenji yoshida
@xuwei-k
May 11 2016 05:36
マクロ使わない範囲でよりボイラプレート減らそうとすると、こういうことすることがある https://gist.github.com/xuwei-k/1a3f7c645a6acf0f13e9a475a6947a93
なので、がくぞーさんの TypeConverter あっても悪くない気もするけど、こっちの「コンパニオン用の親クラス用意しておくパターン」でより手軽にやってしまいたくなった場合は、個人的には(ボイラプレート減らすという意味では)あまり使うことにならないかも?という微妙な感想がある。
単にボイラプレート減らす目的以外でも、両方を継承した TypeConverter 作っておくのは、使いどころある気もするけど
Manabu Nakamura
@gakuzzzz
May 11 2016 06:19
ScalikejdbcValueCompanion 標準に入れても良さそう。 trait にした方がよさそうだけど、そうすると binder とかをメソッドにしないといけなくなるのでインスタンスの数は増える……
kenji yoshida
@xuwei-k
May 11 2016 06:28
implicit parameterで引数取ってるから、単純にtraitにするのはあれだし、あとtraitにしてかつ他のtraitのmixinも考えだすと、初期化考えないといけなくなってくる?みたいな問題はある
ScalikejdbcValueCompanion というのはだいぶ適当に名付けたので、もし本当に入れる流れになるなら、適当に名前変えてもらって構わないです
Manabu Nakamura
@gakuzzzz
May 11 2016 06:29
いや、たんに binderメソッドの引数に implicit T: TypeBinder[A] つけて、 unbinder メソッドの引数に P: ParameterBinderFactory[A] つければいいだけかな、と。
unapply を override とかされてると初期化順を考えないとですけど、それはレアケースかなーと。
はやく trait parameter 使いたい……
kenji yoshida
@xuwei-k
May 11 2016 06:30
あーなるほど。まぁすると型クラスのインスタンス毎回生成される、という、超微妙なトレードオフはありますけどね。
Manabu Nakamura
@gakuzzzz
May 11 2016 06:30
ですです。インスタンスの数が増えちゃってパフォーマンスにはデメリットですね。
別に引数で渡さなくても implicitly でglobalに取得すればよい気もしてきた? それなら val のままいける。
kenji yoshida
@xuwei-k
May 11 2016 06:36
それ、(マクロ使わないなら) 解決するタイミング的に自分の現状と同じになるだけな気が
自分で書いておいてなんだけど、コンパニオン用の親作っておくの、たしかにボイラプレートは減るんだけど、減るの少しだけだし、上記のようないろいろなトレードオフと論点があって、標準に入れたい!と主張するには躊躇われて悩ましいところ・・・
Manabu Nakamura
@gakuzzzz
May 11 2016 06:39
タイミング的には同じですが、companion オブジェクトは他にも mixin させたり継承させたりみたいなのが出てきそうなので、なるべく他のクラスを継承できなくなる、みたいな制限を無くしたい、という感じです。
kenji yoshida
@xuwei-k
May 11 2016 06:42
trait で abstract method にする感じですか?
まぁひとまず任せよう(?)
Manabu Nakamura
@gakuzzzz
May 11 2016 06:45
あれ? 単にこうすればいいかな、みたいな
trait ScalikejdbcValueCompanion[A, B] extends (A => B) {
  def unapply(value: B): Option[A] 
  final implicit lazy val binder: TypeBinder[B] = implicitly[TypeBinder[A]].map(apply)
  final implicit lazy val unbinder: ParameterBinderFactory[B] = implicitly[ParameterBinderFactory[A]].xmap(apply, unapply(_).get)
}
kenji yoshida
@xuwei-k
May 11 2016 06:46
それそのtrait定義時点で implicit not found にならないですか?
Manabu Nakamura
@gakuzzzz
May 11 2016 06:49
あ、そうか、ボケてました。そうですね