ScalaのSymbolについて

ぽんこつ @ponkotuy

ScalaのSymbolリテラル非推奨なのか。Symbol("abc")だと一旦文字列生成するからコスト増になるけど、コレが推奨されるの？

がくぞ @gakuzzzz

@ponkotuy Symbol("abc") はあくまで移行のための手段であって、推奨としてはStringを直接使う方向じゃないですかね？

ぽんこつ @ponkotuy

@gakuzzzz んーなる、Skinny-ORMが存外どっぷりSymbolに依存してるんでどうしたもんかな、みたいな話してた

Kenji Yoshida @xuwei_k

@ponkotuy @gakuzzzz skinny-orm全部Stringに変えるpull reqしましょう(ぇ

ぽんこつ @ponkotuy

@xuwei_k @gakuzzzz 既存のコードと互換性考えると頭痛くしかならない…

Kenji Yoshida @xuwei_k

ちなみに twitter.com/ponkotuy/statu… "一旦文字列生成するからコスト増" が、実行時のコストのことなら、べつにおなじbytecodeになるだけだから、変わらないはず。 (Symbol生成は特殊な最適化がされてるのだが github.com/scala/scala/bl… リテラルでもそうでなくても、この最適化は勝手に適用されるっぽい)

ぽんこつ @ponkotuy

む、そうなのか、勘違いしてた

ぽんこつ @ponkotuy

なんかSymbolのオブジェクトとStringのオブジェクト2つ生成するのは割と馬鹿にならんのではとおもった(symbolリテラルが2つ作らないというのが誤解かな

Kenji Yoshida @xuwei_k

@ponkotuy 詳細に説明できるほど知識ないですが、生成方法を最適化しているだけでSymbol自体はこういう定義だから github.com/scala/scala/bl… キャッシュなければある意味 "SymbolのオブジェクトとStringのオブジェクト2つ生成する" というの自体は間違ってないので、そういう意味ではSymbol自体が微妙というか

kmizu @kmizu

@gakuzzzz @xuwei_k @ponkotuy ちょっと微妙な話がありまして、scaladocにもある通り、Symbol classのオブジェクトはreference equalityでもって比較できる（＝極めて小さい定数時間で処理が完了することが保証されている）ので、用途特化では便利だったりします。ただ、それが便利な用途ってそれこそ言語処理系とか限定かも。

kmizu @kmizu

Symbolのequalsが github.com/scala/scala/bl… であることの意義が実はあまり共有されていない（？）、ということに今気づいたのでした。ただまあ、そのライブラリの意義はあるとしても、リテラル表記はまあ要らないなという話になりそですが。

Kenji Yoshida @xuwei_k

@kmizu @gakuzzzz @ponkotuy はい。でもStringも作られ方によっては "reference equalityで比較される" ことも多いので "必ずreference equalityで比較できる" ことを保証するために github.com/scala/scala/bl… WeakReferenceなど使って生成する部分のパフォーマンスとのトレードオフになって、それはどうなんだ、という問題が…

がくぞ @gakuzzzz

@kmizu @xuwei_k @ponkotuy あ、なるほど。reference equality が保証されてるのであればScalaでもSymbolインスタンスの共有は内部的に行ってるんですね

kmizu @kmizu

@xuwei_k @gakuzzzz @ponkotuy 個人的な見解なんですが、実際にSymbolの比較を高速にしたいシチュエーション考えると、こうやってガチガチに保証するのはオーバーキルでは、と思います（安心して使うためには、というのもわかるんですけど、保証範囲を明確に限定してしまえばいい、とか思います）。

Kenji Yoshida @xuwei_k

Symbolの特殊な最適化といえば、それのせいでsbt-assemblyでshardingするとSymbolがうまく動かない、というissueが報告されていて、なるほどな、と思った twitter.com/xuwei_k/status… github.com/sbt/sbt-assemb…