These are chat archives for scalikejdbc/ja

13th
Feb 2015
ponkotuy
@ponkotuy
Feb 13 2015 09:03
(SeqはStreamも含むから扱い辛いよね、っていう議論があって、結論としてはVectorが便利、だった気がするのでVectorにしたい
Manabu Nakamura
@gakuzzzz
Feb 13 2015 09:12
interface としては IndexedSeq にしておいて Vector を返すのが良い感じですかね?
ponkotuy
@ponkotuy
Feb 13 2015 09:13
んーでもIndexedSeqを積極的に使ってる例を見たことがない
ちなみにinterfaceとはどこのですか
Manabu Nakamura
@gakuzzzz
Feb 13 2015 09:15
findAll とかの戻り値型ですね < interface
ponkotuy
@ponkotuy
Feb 13 2015 09:15
Vector返すならVectorにしておくべきでは
Manabu Nakamura
@gakuzzzz
Feb 13 2015 09:16
ただ今までが List だったから LinearSeq で受け取ってる人とかいたら互換性崩しちゃうか。 generator なら問題無いかな
んー interface に具象クラス書くのは微妙な気がしますが。より効率的な実装が発明された時に変えづらいですし。
ponkotuy
@ponkotuy
Feb 13 2015 09:28
受け取る側がVectorなら使えるメソッドがVectorなのに使えないというデメリットもありまして。まぁIndexedSeqぐらいならそこまで阻害されないと思うけど
Manabu Nakamura
@gakuzzzz
Feb 13 2015 09:34
Vectorとか具象クラス固有のメソッドを通常ケースで使うのはむしろバッドスメルの様な。パフォーマンスチューニングなどのごく僅かなケースで使いたいのであればそこの所でVectorに変換するなりするべきかと
ponkotuy
@ponkotuy
Feb 13 2015 09:40
いやーオーダーで変わるようなパフォーマンスの問題を「ごく僅かなケース」で片付けられるのはちょっとアレだなー
todesking
@todesking
Feb 13 2015 09:44
返り値の型、将来の互換性を壊さない限りでなるべく具体的な型を返したほうが利便性は高まるけど、ケースバイケースっぽい
Vectorに可能でIndexedSeqだと無理な操作って何があるんだろう
KAWACHI Takashi
@tkawachi
Feb 13 2015 09:45
操作を挙げねば話が進まないぽい
Manabu Nakamura
@gakuzzzz
Feb 13 2015 09:45
えっ そういう話なの?
ponkotuy
@ponkotuy
Feb 13 2015 09:46
Listならconsとか::とかが割と。Vectorは思い付かない
Manabu Nakamura
@gakuzzzz
Feb 13 2015 09:46
戻り値の型はなるべく限定された型にした方がいい、というのは同意。
ただ 公開APIの戻り値型はなるべく限定された抽象型にしておいた方が、将来の互換性を壊さない率を高めるので良いと思う派です。
そのために抽象traitと具象クラスが分かれてるんだし
ponkotuy
@ponkotuy
Feb 13 2015 09:49
抽象trait、引数として使うときにできるだけ広い範囲のcollectionで使えるようにするためだと思っていた
KAWACHI Takashi
@tkawachi
Feb 13 2015 09:49
一般的にそう思います。>抽象型の方がいい
ponkotuy
@ponkotuy
Feb 13 2015 09:50
なるほど。じゃあVectorで返すようなのはやめときますか
とはいえそもそもgeneratorで生成されるのが公開APIみたいな奴とは思えない
KAWACHI Takashi
@tkawachi
Feb 13 2015 09:51
具体的にこまる例があれば別ですけど。(適度な抽象度の型が無いとか)
generator はもっと気軽にオレオレのが作れるといいですね。
ponkotuy
@ponkotuy
Feb 13 2015 09:52
Listの::とかは便利過ぎて割と良く使うので具体的に困る。とはいえこれあんまりよくないよね、って言われたらそうかもしれない
Manabu Nakamura
@gakuzzzz
Feb 13 2015 09:53
:: の代わりに +::+ 使いましょう
KAWACHI Takashi
@tkawachi
Feb 13 2015 09:53
(「もっと気軽に」といってみたものの、今どれだけ気軽じゃないのかわかってないという
ponkotuy
@ponkotuy
Feb 13 2015 09:53
やっぱそうですねぇ…
ただListだと x :: xsが良いけど他だとxs :: xの方が早いんだよな…
いや早くないけど
いや場合に依るか
言っててList使わなければ良いのでは、って気がしてきている
Shuya Tsukamoto
@tsukaby
Feb 13 2015 10:56
なるほど、いろいろあるんですね scalaのcollectionは・・・
流れ的にはIndexedSeqにするのが良さそうだけど、もっと自分流にカスタマイズできるとよいって感じでしょうか。generateするときにオプションで戻り値型を自分で指定できればベストなのかな
Manabu Nakamura
@gakuzzzz
Feb 13 2015 11:07
ここまで話しておいてなんですが、 Vector 返すようにするには DBSession#list をそもそも弄るか Vector 返す版つくらないといけないような気がしてきました。 generator 側だけ直すなら Seq か LinearSeq にするぐらいじゃないと厳しそうですね……。
Shuya Tsukamoto
@tsukaby
Feb 13 2015 11:09
あ、LinearSeqか。
kenji yoshida
@xuwei-k
Feb 13 2015 11:13
Scalaにおいて、immutableな汎用的なIndexedSeqってVectorしか存在しないので・・・
scalikejdbcのCodeGeneratorがあまり拡張可能でない、という別の問題はある
kenji yoshida
@xuwei-k
Feb 13 2015 11:32
Vector 版作るじゃなく、 to[C[_]](implicit C: CanBuildFrom[Nothing, A, C[A]]) という感じの汎用的なものを作るべきな気がしてきた
Manabu Nakamura
@gakuzzzz
Feb 13 2015 11:33
確かに。 DBSession が それ持ってるといいですね。
Kazuhiro Sera
@seratch
Feb 13 2015 11:34
いいね
Shuya Tsukamoto
@tsukaby
Feb 13 2015 11:35
難しい・・・!generateしてできたMapperを使うときにfindAll().to[Seq] みたいな感じにするということですか?
Manabu Nakamura
@gakuzzzz
Feb 13 2015 11:37
generate する findAll() の内部実装で session.to[Seq] とか to[Vector] とかするイメージですね
Shuya Tsukamoto
@tsukaby
Feb 13 2015 11:38
なるほど
kenji yoshida
@xuwei-k
Feb 13 2015 12:03
効率の面では内部が全部そうなっていたほうがいいけど、結構変えないといけなくて、途中で一旦諦めた残骸のコミットです xuwei-k/scalikejdbc@cb053b9
誰かissueだけ立てておいて・・・(他人任せ
話がらっと変わりますが、これ https://twitter.com/pocketberserker/status/565370989568352256 をやってみた結果
https://ci.appveyor.com/project/xuwei-k/scalikejdbc/build/1.0.14 テストの実行まではいったけど、
SQL ServerでのJDBCの設定全くわからなくて、結局うまくいってない、という残念情報を共有しておきます
しかも、スペック低い?のか、travisより結構遅くてつらい
pocketberserker
@pocketberserker
Feb 13 2015 12:09
AppVeyor、遅いのでわりと待たされます…