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

椎路ちひろ @ChihiroShiiji

@nagise 拡張可能コンパイラ、最適化のライブラリ化、ドメイン固有言語あたりの統合の目論見ですね。核言語に生成的機能を入れて新しい核言語とし、抽象化手法や最適化手法をライブラリ化しようって話です。

t_yano @t_yano

ああ、たしかに、さっきの発言は、型パラメータ使うくらいならオブジェクトを定義しろっていうように読めてしまう。失言でした。使いどころの違いを言いたかった。

なぎせ ゆうき @nagise

フレームワークだからね @naka_aki_spl やっぱりsessionクラスもしっくりこないなあ。なんで「なんでも入れれるの前提」っていう設計になっちゃってるんだろう？そんな危ない設計に。なんでまたdynamic bean（てゆーのか）みたいなことにしちゃったんだろう？

椎路ちひろ @ChihiroShiiji

@nagise （構文的にはスマートとは言い難いですが）C++のテンプレート・メタプログラミングである程度は可能なことは実証されています。総称と継承が互いで互いを実現できるというのはEiffel本でも触れられている古典的な話ですし。

加藤潤一(かとじゅん) @j5ik2o

#Scala でクロージャ厨になりつつある。麻疹は早く終わらせよう。Javaでクロージャは2012年まで待つ必要があるのだから、Scalaの重力で時を加速させるだ...。

t_yano @t_yano

ScalaをJavaの延長、いうなればBetter Javaとして捉えるとなんかおかしくなるので、完全に別の言語だと思った方がいいと思うんだよね。完全に別の言語なので、両者での解決方法はおのずから変わってくると思う。まあなんというか、逆にいうといっていったらいいのか、（つづく）

非実在naka aki @naka_aki_spl

@nagise sessionについては、「xxクラスを継承したうえで、そこに必要な属性を足しなさい」という流れ（FW設計）が、あれくらいの時代なら（でも）有りそうなもんだったろうにって感じがしました。 serializableとかの仕組みは既にあったわけだし。

t_yano @t_yano

ScalaはJavaの欠点の多くに解決策を提示しているのだけど、Javaと（設計的に）互換性のある言語ってわけじゃなくて、あえてJavaが大事にしてたところを捨ててるってところもあると思うんだよね。だから、私は別の言語として接したい。Haskellに接するのと同じくらい違う。

しいたけ @yuroyoro

@j5ik2o 次はinfix type でtype %%[A,B] = (A,B) ;val v:Int %% String = (1,"foo");と書く厨置病や、new書きたくない病,matchよりforやflatMap病が待ってます #Scala

なぎせ ゆうき @nagise

@naka_aki_spl んー。結局特定のクラスを継承して作ったところで、ナローキャスト発生してどのみちローレベルでは微妙な感じになるんじゃ。ジェネリクスあってもあの部分は普通にはどうにもならんでしょ

しいたけ @yuroyoro

あとは演算子メソッドや:つけた右結合メソッド多用とか

非実在naka aki @naka_aki_spl

@nagise あれ？俺なにか（また）勘違いしてるかな？ 今のMap的なやりかたじゃなくBean的なやりかたなら良かったんじゃないかと思ってる感じです。

椎路ちひろ @ChihiroShiiji

@nagise イレイジャは既存のVMやクラスファイルと総称を適合させる仕組みだから。最適化など性能的メリットがないのでVMの基盤自身が変わってしまうと使われなくなってしまうかも…。

加藤潤一(かとじゅん) @j5ik2o

@yuroyoro apply, unapplyは使い始めて、ちょっと熱が下がって微熱っぽいです。あ、unaray_*は知らない。クソーまだ免疫がｗ

なぎせ ゆうき @nagise

@naka_aki_spl そのBeanを最後どうやって型安全にセッションに格納するの？まぁいまでもセッションに格納するオブジェクトを１つだけにしてその型にフィールド宣言する手法がよくつかわれるわけだけど

非実在naka aki @naka_aki_spl

@nagise あ。やっぱり「よくつかわれる」んだ。よかったー。身近じゃ全然みたことないので何かあるのかと思ってたよ。。。

なぎせ ゆうき @nagise

@naka_aki_spl だからその型安全じゃないところをプロジェクトの中で局所的にしてできるだけ隠ぺいしたいってのはあると思う。今回のは今のJavaの型システムで無理やり型安全にしてやったぜっていう

椎路ちひろ @ChihiroShiiji

@nagise そういう方向性だとVMにクラスなんか扱わせないでいいじゃんというLLVMや型つきアセンブラとかが取ってる方向もあったりしまして。

なぎせ ゆうき @nagise

そもそもそこまでするぐらいなら、たかだかひとつクラスを作ってセッションに格納する情報は全部これにいれるから！ってやったほうがシンプルで効果的なんだよね。それで十分許容できるよねって

t_yano @t_yano

ランタイムに型情報が消えてるってのは、Javaらしくないんだよな＞イレイジャ

なぎせ ゆうき @nagise

@ChihiroShiiji ですね。まぁJavaVMは好きなんだけど、Javaの言語仕様に引きずられているところがかなりあるから、より強烈な型システムを作ろうとするとイレイジャ方式にならざるを得ないというか

t_yano @t_yano

型パラメータがなければ旧式のバイトコードに、ついてたら新式のバイトコードにコンパイルする、とかできなかったんかなー

なぎせ ゆうき @nagise

いわれてみるとそうかもしれない。イレイジャなのがJavaと思ってたから考えたことなかったけど @t_yano ランタイムに型情報が消えてるってのは、Javaらしくないんだよな＞イレイジャ

非実在naka aki @naka_aki_spl

@t_yano ぜひ欲しかったなあ。java5のアレって次の10年をまた「失われた１０年」にしてしまいかねない爆弾じゃねかとも少し思う。

t_yano @t_yano

まああのころって、Java 5でコンパイルされたクラスファイルはJava 1.4でも動くようになると言われてたんだよな。それが実現不可能だと分かった段階で、新旧織り交ぜる、という方向には走れなかったのかどうか。あるいは技術的に難しいのか。あるいは時間がなかったのか。