Java による高階型変数と Scala とジェネリクス

なぎせ ゆうき @nagise

型変数に型変数持てないのが辛いなあ

椎路ちひろ @ChihiroShiiji

@nagise …というのは型関数？（型を引数にとって型を返す関数）それとも高階型関数？（型関数を受け取ったり返したりできる関数）

なぎせ ゆうき @nagise

@ChihiroShiiji Javaの場合、スコープがメソッドの型変数と、スコープがインスタンスの型変数があるわけですが、二階層に使いたい場合、型変数自身に型変数を持つ必要が出てくるんです

椎路ちひろ @ChihiroShiiji

@nagise 変数が変数を持つという表現は判りにくいので、型変数の解決を一種の関数適用（数学の意味で）と考えて、型変数を引数、引数に具体的な型を当てはめたもの（この置換で結果によりその型変数は消える）を結果という感じに整理して考えましょうかと…。

なぎせ ゆうき @nagise

@ChihiroShiiji うーむ。そういう意味では２元の型変数なのかな

なぎせ ゆうき @nagise

blog書いた。「HttpSessionを型安全にする」 http://d.hatena.ne.jp/Nagise/20110122/1295664922 本題はその過程で出てくるジェネリクスの未解決問題の提示

なぎせ ゆうき @nagise

@daisuke_m 例の奴、うっかり型安全化に成功しちゃった。詳しくは夜にBlog書きますわ

なぎせ ゆうき @nagise

Javaだとインスタンスのインスタンス、言うなれば高階インスタンスのようなことが出来て、僕はこのプログラミングパラダイムが結構好きなんだけど、世の中にはパラダイムとしては認知されてないね

なぎせ ゆうき @nagise

blog書いた http://d.hatena.ne.jp/Nagise/20110124/1295874192 Javaによる高階型変数の実装

くっくっkura 🇯🇵🦀 @PG_kura

"その昔「たかしな」と読んだ人がいたとか、いないとか。" / 『Javaによる高階型変数の実装』 プログラマーの脳みそ http://goo.gl/wRjxK

しいたけ @yuroyoro

俺は型安全というのはコンパイル時に型の合わない代入を許容しないことだと思っていて、「実行時にClassCastExceptionが出る」ような実装は型安全では無いと思う。

しいたけ @yuroyoro

要素型Ｔを型変数に取るMapがあったとして、そのコレクションに対するget(key)の結果型がkeyの値によって型付けされるためには、コンパイラはkeyに対してどんな型の値が入ってるか知らなくてはならない。つまり、コンパイル時にデータそのものが決定されている必要がある

なぎせ ゆうき @nagise

@yuroyoro 今回の場合はキーがあらかじめ列挙できる想定でしたけどね。列挙できないなら当然コンパイル時に解決しきれない

しいたけ @yuroyoro

@nagise keyを列挙できる=型にエンコードできる、だと思います。静的な型付けでは外部の入力に対して型付けが出来ないの。列挙できるなら、そもそもコレクションクラスの形態を取る必要はなく、ふつーのクラスでもいいのではと思いました

なぎせ ゆうき @nagise

@yuroyoro そう。単品なら普通のクラスにしちゃえばいい。抽象化しようというのがそもそもやりすぎともいえる。動機はHttpSessionみたいなケースをどうにかしたかった訳なんだけど

しいたけ @yuroyoro

@nagise やっぱりコンパイル時に決定できない計算に対しては、nominal typingによる制限しか表現の仕様が無い気がしますね。Vの型はある型以上であるとか、Keyはある型かそのサブタイプか、とか。それとも俺が知らないだけでもっといい型システムがあるのかな?

なぎせ ゆうき @nagise

ヘビィなジェネリクスってのはたいていの場合、そこまで抽象化する必要はなく、ちょっとだけDRY原則を破ったほうがトータルでコスト安であることが多い

かとじゅん @j5ik2o

WicketのSessionクラスはどうだったかな。。 RT @nagise: @yuroyoro そう。単品なら普通のクラスにしちゃえばいい。抽象化しようというのがそもそもやりすぎともいえる。動機はHttpSessionみたいなケースをどうにかしたかった訳なんだけど

なぎせ ゆうき @nagise

まぁ、やれないと思ってたら、やれないことはないって思いついちゃったってのが今回は強いかな

非実在naka aki @naka_aki_spl

@yuroyoro この十数年未だにしっくり来てないんですけど、sessionに１こだけbean入れるって運用にして、そのbeanに必要（というか十分）な数のメンバをつけて。。。だと何が不味いんでしたっけ？

しいたけ @yuroyoro

@naka_aki_spl 粒度しだいですけど、そういう実装は得てして重複した構造があちこちに散らばってDRYじゃなくなりがちですね

しいたけ @yuroyoro

なんかこういう発想しちゃうのって最近少しHaskellかじってるからだろうか……

非実在naka aki @naka_aki_spl

@yuroyoro sessionを名前不安全にアクセスする通常のスタイルでも「構造」はそこに存在するわけですよね。コードに明示的に書けないせいでヤラしくなるという違いがある（だけ。。。てのもなんだが）で、同じなんじゃないのかなあと思うんです。

t_yano @t_yano

@j5ik2o Wicketの場合、Sessionクラス自体自分で作るのだから、setAttributeとかgetAttributeとか関係なくて、自分でメソッド作るのだからタイプセーフですよ。

t_yano @t_yano

型安全をタイプパラメータでやるのは限界があるので、やっぱちゃんとオブジェクト作るのがベストだと思うよ、オブジェクト指向的にはね。