Scala初心者ですが、よろしくお願いします!
Scala
May 18, 2011 ~ March 28, 2012
200 messages
悔しいので、2.8系のCollectionで独自のコレクションクラスを実装する方法について書いてやる
<pre>悔しいので、2.8系のCollectionで独自のコレクションクラスを実装する方法について書いてやる</pre>
IterableLike[A,Repr]とかTravesavleLike[A,Repr]とかいうトレイトがあるのでソイツを実装すればよい。Aは要素型、Reprはコレクションの内部表現な。Reprは型コンストラクタになってる
<pre>IterableLike[A,Repr]とかTravesavleLike[A,Repr]とかいうトレイトがあるのでソイツを実装すればよい。Aは要素型、Reprはコレクションの内部表現な。Reprは型コンストラクタになってる</pre>
def canBuildFrom: CanBuildFrom[Repr, A, Repr]
<pre>def canBuildFrom: CanBuildFrom[Repr, A, Repr]</pre>
scala> true ?? {s:String => s * 2 } apply "おっぱい"
res1: String = おっぱいおっぱい
<pre>scala> true ?? {s:String => s * 2 } apply "おっぱい" res1: String = おっぱいおっぱい</pre>
Scalaでは、識別子として許容されている記号(+,-,*,/,=,<,>,...) があって、それを任意に組み合わせた識別子を作ることができます。
<pre>Scalaでは、識別子として許容されている記号(+,-,*,/,=,<,>,...) があって、それを任意に組み合わせた識別子を作ることができます。</pre>
たとえば、 +++++++++++++======+++++++++++++++ とかも、識別子としてvalidです。
<pre>たとえば、 +++++++++++++======+++++++++++++++ とかも、識別子としてvalidです。</pre>
Scalaでは、 receiver identifier(いわゆる演算子含む) parameter は、
<pre>Scalaでは、 receiver identifier(いわゆる演算子含む) parameter は、</pre>
だから、 1 + 2 も、Scalaでは、(1).+(2) というメソッド呼び出しになります(ただし、いわゆるプリミティブ型に関しては、コンパイラがboxingが必要なければ、intとかにコンパイルするので、実行性能は落ちません)
<pre>だから、 1 + 2 も、Scalaでは、(1).+(2) というメソッド呼び出しになります(ただし、いわゆるプリミティブ型に関しては、コンパイラがboxingが必要なければ、intとかにコンパイルするので、実行性能は落ちません)</pre>
あとは、記号による「いわゆる演算子」には優先順位があって、演算子の最初の1文字が+/-/*/...のどれかによって、優先順位が一意に決まります。
<pre>あとは、記号による「いわゆる演算子」には優先順位があって、演算子の最初の1文字が+/-/*/...のどれかによって、優先順位が一意に決まります。</pre>
たとえば、 1 + 2 * 3 はSmalltalk式だと、 (1 + 2) * 3 になっちゃいますが、
<pre>たとえば、 1 + 2 * 3 はSmalltalk式だと、 (1 + 2) * 3 になっちゃいますが、</pre>
これは、ほぼJavaの演算子の優先順位と同じになるように決められているので、通常はあえて意識しなくても良いです。
<pre>これは、ほぼJavaの演算子の優先順位と同じになるように決められているので、通常はあえて意識しなくても良いです。</pre>
?? は何をするメソッドですかー?あとググらビリティがすごい低いと思うのですが、??が何をするメソッドかどうか調べるのはどうするのが早いですか?
<pre>?? は何をするメソッドですかー?あとググらビリティがすごい低いと思うのですが、??が何をするメソッドかどうか調べるのはどうするのが早いですか?</pre>
receiverはBoolean型で、receiverの評価結果がtrueなら arg を評価します。
<pre>receiverはBoolean型で、receiverの評価結果がtrueなら arg を評価します。</pre>
たとえば、argがIntなら0、Doubleなら0.0、Booleanならfalseといった感じです。
<pre>たとえば、argがIntなら0、Doubleなら0.0、Booleanならfalseといった感じです。</pre>
manglingされた"$qmark$qmark"だとひっかかりやすくなりますね。あと、なんかツールがあった気がしますが、なんだったかな…。
<pre>manglingされた"$qmark$qmark"だとひっかかりやすくなりますね。あと、なんかツールがあった気がしますが、なんだったかな…。</pre>
scalexは、出たばっかりのときはあまり使えなかったですけど、最近試したら普通に使えるようになってたので
<pre>scalexは、出たばっかりのときはあまり使えなかったですけど、最近試したら普通に使えるようになってたので</pre>
scalazの背景にあるコンセプトを理解しないと、逆に読みづらい、と感じてしまうと思うので。
<pre>scalazの背景にあるコンセプトを理解しないと、逆に読みづらい、と感じてしまうと思うので。</pre>
弊社の新人が記事かいたので、よかったらつっこみとかお願いしますだ。http://lab.dwango.jp/articles/fascinating-scala.html
<pre>弊社の新人が記事かいたので、よかったらつっこみとかお願いしますだ。http://lab.dwango.jp/articles/fascinating-scala.html</pre>
implicit conversionは使いどころが難しいので、「自分たちでは使わない」という規約を定めるのも一つだと思います。Twitterは確かそういうコーディング規約で運用していたはず。
<pre>implicit conversionは使いどころが難しいので、「自分たちでは使わない」という規約を定めるのも一つだと思います。Twitterは確かそういうコーディング規約で運用していたはず。</pre>
そのときは、情報ソース見て書いたはずなのですが…。a3xがTwitterに居た頃のコーディング規約の話だったか。ともあれ、ソースがわからなくなってますが、基本的にそうだったと記憶しています。
<pre>そのときは、情報ソース見て書いたはずなのですが…。a3xがTwitterに居た頃のコーディング規約の話だったか。ともあれ、ソースがわからなくなってますが、基本的にそうだったと記憶しています。</pre>
今のScalaではimplicit conversion使わないとかあまり考えられない。
<pre>今のScalaではimplicit conversion使わないとかあまり考えられない。</pre>
かってに実行されるauto-boxinigなんかより、自分で制御できるimplicit conversionの方がよっぽどお行儀がいいと思うから、不必要に恐れることない。
<pre>かってに実行されるauto-boxinigなんかより、自分で制御できるimplicit conversionの方がよっぽどお行儀がいいと思うから、不必要に恐れることない。</pre>
自分で書くコードでimplicit conversionを定義しなくても、Scalaのメリットはそれなりにあるのではないかと。現在のScala関係のプロジェクトでimplicit conversion定義してないのがあるか、っていう
<pre>自分で書くコードでimplicit conversionを定義しなくても、Scalaのメリットはそれなりにあるのではないかと。現在のScala関係のプロジェクトでimplicit conversion定義してないのがあるか、っていう</pre>
そりゃ使わなくてもメリットはあると思いますけど、だからといってimplicit conversionは危ない、みたいな通説ができるのはよくないと思います。
<pre>そりゃ使わなくてもメリットはあると思いますけど、だからといってimplicit conversionは危ない、みたいな通説ができるのはよくないと思います。</pre>
だいたい、OpenClassで好き放題パッチあてるRubyのメタプログラミングの方がよっぽどコワイ。
<pre>だいたい、OpenClassで好き放題パッチあてるRubyのメタプログラミングの方がよっぽどコワイ。</pre>
それは同意です。自分で制御不能な分。 >OpenClassで好き放題パッチあてるRubyのメタプログラミングの方がよっぽどコワイ。
<pre>それは同意です。自分で制御不能な分。 >OpenClassで好き放題パッチあてるRubyのメタプログラミングの方がよっぽどコワイ。</pre>
でも、Rubyのメタプログラミングはちゃんとお作法や、「みんなこう書く」みたいのが広まってるので
<pre>でも、Rubyのメタプログラミングはちゃんとお作法や、「みんなこう書く」みたいのが広まってるので</pre>
なるほど。scalazとか、implicit conversionに関する規約がわかりやすいので、ああいうのが必要とか。scalaz自体はいきなり使うべきじゃないと思いますが。
<pre>なるほど。scalazとか、implicit conversionに関する規約がわかりやすいので、ああいうのが必要とか。scalaz自体はいきなり使うべきじゃないと思いますが。</pre>
型クラスの概念を理解しないとコードが理解できない、という意味で。 >いきなり使うべきじゃない
<pre>型クラスの概念を理解しないとコードが理解できない、という意味で。 >いきなり使うべきじゃない</pre>
そーですね。あと、PimpedType[T]を継承するとか、あの辺りも良い規約(型から探索しやすいので)だと思うのですが、PimpedType[T]が標準ライブラリに無いから…
<pre>そーですね。あと、PimpedType[T]を継承するとか、あの辺りも良い規約(型から探索しやすいので)だと思うのですが、PimpedType[T]が標準ライブラリに無いから…</pre>
でも、自分たちのプロジェクトで使うときに、implicit conversionによる機能拡張を提供するクラスに共通の祖先クラスを定義しておく、という形でなら、難易度は高くないか…
<pre>でも、自分たちのプロジェクトで使うときに、implicit conversionによる機能拡張を提供するクラスに共通の祖先クラスを定義しておく、という形でなら、難易度は高くないか…</pre>
ともあれ、そういうのをチャットでだけ話すと後に残らないので、文書化していく必要がありますね。
<pre>ともあれ、そういうのをチャットでだけ話すと後に残らないので、文書化していく必要がありますね。</pre>
ユーザーズグループのサイトに、ドキュメントのページ作るか、それとも半公式Wikiを作って、そこへのリンク貼るとか。
<pre>ユーザーズグループのサイトに、ドキュメントのページ作るか、それとも半公式Wikiを作って、そこへのリンク貼るとか。</pre>
ちょっとお願いしたいことがあるのですが、Scalaユーザーズグループ発足後、公式MLがpublicに公開される事になりますが、とりあえず、特に初学者の方が躊躇せずに済むように、何かScalaに関する質問があればML
<pre>ちょっとお願いしたいことがあるのですが、Scalaユーザーズグループ発足後、公式MLがpublicに公開される事になりますが、とりあえず、特に初学者の方が躊躇せずに済むように、何かScalaに関する質問があればML</pre>
に投げていただけないでしょうか。特に、yamashiro さん辺り、お願いできると助かるのですが。もちろん、サクラとかそういうのではなく、普通に疑問に
<pre>に投げていただけないでしょうか。特に、yamashiro さん辺り、お願いできると助かるのですが。もちろん、サクラとかそういうのではなく、普通に疑問に</pre>
# ユーザーズグループ発足の話は、もうそこまで伏せる必要はないかなと思って、このチャットで書くことにしました。それに、このチャットに居る人自体が少ないのでw
<pre># ユーザーズグループ発足の話は、もうそこまで伏せる必要はないかなと思って、このチャットで書くことにしました。それに、このチャットに居る人自体が少ないのでw</pre>
日本Scalaユーザーズグループは12/10(土)に正式発表&サイト+MLオープンの予定で準備が進んでいます。
<pre>日本Scalaユーザーズグループは12/10(土)に正式発表&サイト+MLオープンの予定で準備が進んでいます。</pre>
おー新しくできるんですか。私は最近ほとんどScala触れてなくてアレですが、機会があったら利用してみたいと思います。
<pre>おー新しくできるんですか。私は最近ほとんどScala触れてなくてアレですが、機会があったら利用してみたいと思います。</pre>
そう言えば以前 scala-be って言うのがあったよなーと思って ML 見てみたら最後の投稿が2010/10/08だった。
<pre>そう言えば以前 scala-be って言うのがあったよなーと思って ML 見てみたら最後の投稿が2010/10/08だった。</pre>
scala-beが上手くいかなかった理由は、当時、今ほどScalaが注目されていなかったとか、Scala自体の成熟度にもまだ問題があったとか、scala-beを上手く機能させるための戦略というかそういうのが無かったとか
<pre>scala-beが上手くいかなかった理由は、当時、今ほどScalaが注目されていなかったとか、Scala自体の成熟度にもまだ問題があったとか、scala-beを上手く機能させるための戦略というかそういうのが無かったとか</pre>
scala-be発足時と違って、基本となるツールチェインのデファクトスタンダードがほぼ確定
<pre>scala-be発足時と違って、基本となるツールチェインのデファクトスタンダードがほぼ確定</pre>
していますし、Webフレームワークも、Typesafeがプッシュしていることから、おそらくPlay! 2.0が中心になると思います。
<pre>していますし、Webフレームワークも、Typesafeがプッシュしていることから、おそらくPlay! 2.0が中心になると思います。</pre>
その辺りのリソースの翻訳など含めて、より実践的に色々記事を書いたり、MLを通じた意見交換とかができれば、という感じです
<pre>その辺りのリソースの翻訳など含めて、より実践的に色々記事を書いたり、MLを通じた意見交換とかができれば、という感じです</pre>
あとは、最近、地方を含めて、各地でのScala勉強会が盛んなのですが、ハブとなるべきコミュニティが不在なので、重複した努力を行っている面があると思うのですよね。
<pre>あとは、最近、地方を含めて、各地でのScala勉強会が盛んなのですが、ハブとなるべきコミュニティが不在なので、重複した努力を行っている面があると思うのですよね。</pre>
ですから、各地のScalaコミュニティのハブとなるコミュニティというのも一つの目的です。
<pre>ですから、各地のScalaコミュニティのハブとなるコミュニティというのも一つの目的です。</pre>
あとは、Scalaでのベストプラクティス、というか、こうすればいい、というのは完全にではないにせよ、Scalaな人の間では醸成されつつある気がするのですが、それがたぶん共有されてない。
<pre>あとは、Scalaでのベストプラクティス、というか、こうすればいい、というのは完全にではないにせよ、Scalaな人の間では醸成されつつある気がするのですが、それがたぶん共有されてない。</pre>
と、細かい目的としては色々あるのですが、根本的には、Scalaに関する暗黙知をできるだけ形式知にして、コミュニティ間で共有していこう、ということになるかと思います。
<pre>と、細かい目的としては色々あるのですが、根本的には、Scalaに関する暗黙知をできるだけ形式知にして、コミュニティ間で共有していこう、ということになるかと思います。</pre>
「何かScalaに関する質問があればML
¶
に投げていただけないでしょうか。特に、yamashiro さん辺り」
<pre>「何かScalaに関する質問があればML ¶ に投げていただけないでしょうか。特に、yamashiro さん辺り」</pre>
当然「過去ログ嫁ばわかるじゃん」レベルの質問とか、そもそも、Scalaの言語じたいじゃない、「○○をするプログラムはどうかけばいいのですか?」みたいな質問はそのうちくると思います
<pre>当然「過去ログ嫁ばわかるじゃん」レベルの質問とか、そもそも、Scalaの言語じたいじゃない、「○○をするプログラムはどうかけばいいのですか?」みたいな質問はそのうちくると思います</pre>
技術系の様々なMLを足場にして、Scala MLがよりよい場になるように僕も強力したいです
<pre>技術系の様々なMLを足場にして、Scala MLがよりよい場になるように僕も強力したいです</pre>
モヒカンには「どんなコード読んでも勉強になるよ」って言われたけど、このコードはScalaっぽいし綺麗だよっていうライブラリとかフレームワークのコード教えて欲しいです。
<pre>モヒカンには「どんなコード読んでも勉強になるよ」って言われたけど、このコードはScalaっぽいし綺麗だよっていうライブラリとかフレームワークのコード教えて欲しいです。</pre>
書いた Scalaプログラマレベル(アプリケーション/ライブラリ)[翻訳] - ゆろよろ日記 : http://d.hatena.ne.jp/yuroyoro/20111209/1323426445
<pre>書いた Scalaプログラマレベル(アプリケーション/ライブラリ)[翻訳] - ゆろよろ日記 : http://d.hatena.ne.jp/yuroyoro/20111209/1323426445</pre>
先行して、日本Scalaユーザーズグループ (Google Groups) http://groups.google.com/group/scala-jp/subscribe?hl=ja&pli=1
<pre>先行して、日本Scalaユーザーズグループ (Google Groups) http://groups.google.com/group/scala-jp/subscribe?hl=ja&pli=1</pre>
<pre>> http://lab.dwango.jp/articles/fascinating-scala.html</pre>
PhantomTypes のところ、この例だけだとJavaでも書けちゃうんですよね。xuwei_kさんも指摘されてましたけど。
<pre>PhantomTypes のところ、この例だけだとJavaでも書けちゃうんですよね。xuwei_kさんも指摘されてましたけど。</pre>
sealed trait Normalize
trait Normalized extends Normalize
trait Unnormalized extends Normalize
//そしてベクトルクラスを作成します
object Vec {
def create(posX: Double, posY: Double) =
Vec[Unnormalized](posX, posY)
}
case class Vec[A <: Normalize] private (posX: Double, posY: Double) {
def normalize = {
import scala.math.sqrt
val abs = sqrt(posX*posX + posY*posY)
Vec[Normalized](posX/abs, posY/abs)
}
}
<pre>sealed trait Normalize trait Normalized extends Normalize trait Unnormalized extends Normalize //そしてベクトルクラスを作成します object Vec { def create(posX: Double, posY: Double) = Vec[Unnormalized](posX, posY) } case class Vec[A <: Normalize] private (posX: Double, posY: Double) { def normalize = { import scala.math.sqrt val abs = sqrt(posX*posX + posY*posY) Vec[Normalized](posX/abs, posY/abs) } }</pre>
case class Vec[A <: Normalize] private (posX: Double, posY: Double) {
def normalize(implicit constraint: A =:= Unnormalized) = {
import scala.math.sqrt
val abs = sqrt(posX*posX + posY*posY)
Vec[Normalized](posX/abs, posY/abs)
}
}
<pre>case class Vec[A <: Normalize] private (posX: Double, posY: Double) { def normalize(implicit constraint: A =:= Unnormalized) = { import scala.math.sqrt val abs = sqrt(posX*posX + posY*posY) Vec[Normalized](posX/abs, posY/abs) } }</pre>
scala> Vec.create(1.0, 2.0).normalize.normalize
<console>:13: error: Cannot prove that Normalized =:= Unnormalized.
Vec.create(1.0, 2.0).normalize.normalize
^
<pre>scala> Vec.create(1.0, 2.0).normalize.normalize <console>:13: error: Cannot prove that Normalized =:= Unnormalized. Vec.create(1.0, 2.0).normalize.normalize ^</pre>
で、これは、Vecの型パラメータAがUnnormalizedのみ呼び出せる、という制約を表現しています。
<pre>で、これは、Vecの型パラメータAがUnnormalizedのみ呼び出せる、という制約を表現しています。</pre>
後で、ブログの方にもちょこっとツッコミ入れときますが、本来はこんな感じのテクニックですよ、という。
<pre>後で、ブログの方にもちょこっとツッコミ入れときますが、本来はこんな感じのテクニックですよ、という。</pre>
相談 こんなことしたい。https://gist.github.com/1518723
<pre>相談 こんなことしたい。https://gist.github.com/1518723</pre>
Dispatchが意外に便利な件。記号使いまくりで、これは無いわーとか思ってたけど、案外わかりやすい。
<pre>Dispatchが意外に便利な件。記号使いまくりで、これは無いわーとか思ってたけど、案外わかりやすい。</pre>
val status = url(STATUS_URL.format(token, "2012-01-01T09:00:00Z"))
val statusResponse = http(status >- (json => JSON.parseRaw(json))
<pre> val status = url(STATUS_URL.format(token, "2012-01-01T09:00:00Z")) val statusResponse = http(status >- (json => JSON.parseRaw(json))</pre>
(json => JSON.parseRaw(json)) の部分を、定数として用意してやれば
<pre>(json => JSON.parseRaw(json)) の部分を、定数として用意してやれば</pre>
<< (String) で、送りたいデータを設定できて、しかも、そうするとRequestを勝手にPOSTにしてくれるとか暗黙ルールがあるので、その辺、ドキュメント読まないとわかりにくいですが。
<pre><< (String) で、送りたいデータを設定できて、しかも、そうするとRequestを勝手にPOSTにしてくれるとか暗黙ルールがあるので、その辺、ドキュメント読まないとわかりにくいですが。</pre>
記号プログラミング、というか、DSLとして見ると結構設計に一貫性があってわかりやすいと思うんですよ。
<pre>記号プログラミング、というか、DSLとして見ると結構設計に一貫性があってわかりやすいと思うんですよ。</pre>
<<<とか、<<はリクエストを組み立てるためのメソッドで、それ自体は状態を変化させない。
<pre><<<とか、<<はリクエストを組み立てるためのメソッドで、それ自体は状態を変化させない。</pre>
で、<<<(stringBody: String)だと、PUTリクエスト(stringBodyを送る)を返す。<<(stringBody: String)だと、POSTリクエスト(stringBodyを送る)、のように、Request組み立てるためのメソッド群が用意されています。
<pre>で、<<<(stringBody: String)だと、PUTリクエスト(stringBodyを送る)を返す。<<(stringBody: String)だと、POSTリクエスト(stringBodyを送る)、のように、Request組み立てるためのメソッド群が用意されています。</pre>
<pre>http://databinder.net/dispatch-doc/#dispatch.RequestVerbs</pre>
見ると大体わかります。ポイントは、<<<とか<<とかは、既存のRequestを変換した新しいRequestを返すところで、それ自体では副作用を発生させないことでしょうか。
<pre>見ると大体わかります。ポイントは、<<<とか<<とかは、既存のRequestを変換した新しいRequestを返すところで、それ自体では副作用を発生させないことでしょうか。</pre>
DispatchはScaladocを参照して使うタイプのライブラリじゃなくて、DSLとして考えればそんなにキモくないと思いました。
<pre>DispatchはScaladocを参照して使うタイプのライブラリじゃなくて、DSLとして考えればそんなにキモくないと思いました。</pre>
implicit conversionをあちこちで使っているので、逆にScaladoc見ただけだと理解しづらいですが…
<pre>implicit conversionをあちこちで使っているので、逆にScaladoc見ただけだと理解しづらいですが…</pre>
DSLって一度使い方を覚えると直感的で便利なんですけど、知らないとそれこそ本当に別言語なんですよね。利点であり欠点でもある。
<pre>DSLって一度使い方を覚えると直感的で便利なんですけど、知らないとそれこそ本当に別言語なんですよね。利点であり欠点でもある。</pre>
UnfilteredはJettyとの相性がよさそうですが、Tomcatとはどうなんだろう的なことを調べている。
<pre>UnfilteredはJettyとの相性がよさそうですが、Tomcatとはどうなんだろう的なことを調べている。</pre>
IDE: IntelliJ IDEA + Scala / Scala IDE for Eclipse、HTTPクライアント:Dispatch、O/Rマッパー:Squeryl、なんか(HTTPじゃない)サーバ書いてみる:Finagle、とりあえずなんか簡単なHTTPサービス作ってみる:Unfiltered、IO:scala-io みたいな感じで、自分の中でno定番ツールセットが決まって来た感が少し。
<pre>IDE: IntelliJ IDEA + Scala / Scala IDE for Eclipse、HTTPクライアント:Dispatch、O/Rマッパー:Squeryl、なんか(HTTPじゃない)サーバ書いてみる:Finagle、とりあえずなんか簡単なHTTPサービス作ってみる:Unfiltered、IO:scala-io みたいな感じで、自分の中でno定番ツールセットが決まって来た感が少し。</pre>
O/Rマッパーはまだ試用中な感が多分にありますが、HTTPクライアントはDispatchで結構鉄板な気がします。
<pre>O/Rマッパーはまだ試用中な感が多分にありますが、HTTPクライアントはDispatchで結構鉄板な気がします。</pre>
あとは、Typesafe Stackがうまいこと、主要ライブラリ群をまとめてくれればいうことなしですかね。
<pre>あとは、Typesafe Stackがうまいこと、主要ライブラリ群をまとめてくれればいうことなしですかね。</pre>
<pre>https://github.com/playframework/Play20/blob/master/samples/scala/computer-database/app/models/Models.scala</pre>




