次世代Javaの動向　２

1 名前：デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:03:42 ] 前スレ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 関連スレ 【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】 pc8.2ch.net/test/read.cgi/tech/1094891986/ www.itmedia.co.jp/news/articles/0404/07/news018.html マルチタスク実現へJava言語改良 Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、 Javaバーチャルマシン（JVM）のアプリケーション共有を強化する「分離」機能が備わり、 ローカライズコンピューティング処理実行のための分離が可能になるという。 米Sun Microsystemsは、Javaバーチャルマシン（JVM）内部での アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。 カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。 SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、 今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、 JVMのアプリケーション共有を強化する「分離」機能が備わる。 この機能によってローカライズコンピューティング処理実行のための分離が 可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。 　またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、 J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。 255 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 09:42:15 ] Iterator → デザインパターンってヤツは誤解しているぞ。 IteratorはCLUで70年代からある。 256 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 11:46:58 ] >>253 MapをIteratorに変換するか MapとListが一緒になった、Jakarta Commons Collectionsにある あのクラスを使えば医院ジャマイカ？ 257 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 11:47:34 ] >>255 GoFの一つにIteratorパターンがあるからね。 デザインパターンとしてのIteratorは後から出たモノだとおもう 258 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 11:51:11 ] >>254 それだと、Entryからkeyとvalueを取り出さなきゃいけないじゃん。 253だとその手間が省ける。それが大事。 259 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 12:04:53 ] そこまで大事か？ 260 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 12:40:00 ] >>259 まあ、あれば便利かもしれんが、そこまで重要な機能ではないわな。 foreachに比べると、使う機会も少ないだろうし。 261 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 19:25:26 ] つうか、>>253くらいのことは簡単に実装できるんだから、拡張for文を導入するときに いっしょに導入してくれればよかったんだよ。 そのくらい、ふつうに気がつくだろ。なんで直接Mapが使えないように限定するのかさっぱりわからん。 262 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 19:40:33 ] >>261 そんなこと言ってると あれも入れろこれも入れろで収拾付かなくなるから。 263 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 19:49:14 ] Entry回せばいいじゃん、極一部のクラスのためだけにそんな馬鹿な仕様取り入れるかよ Collectionはデータ構造に関するJavaの主要フレームワークの根元だから特別視されるだけだ 264 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 20:08:49 ] try-open-finally-closeも特別扱いしてほしい。 265 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 20:13:57 ] try-finallyデストラクタを強制するためにも openとcloseは例外を投げる設計にしたほうがいいんだよな >>264 どんな感じの？ 266 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 20:40:25 ] >>262 そのくせプロパティやらXML直書きやらは導入されるんだ。 そっちのほうが収拾つかんわ。 267 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 20:44:59 ] >>266 Map の foreach なんて generics+プロパティ導入で e.key と e.value で済むんだから わざわざ入れなくてもいいだろ。 268 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 22:08:03 ] クロージャが出来るそうだから、 foreach(aMap, クロージャ); でいいよ。 269 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 01:47:50 ] クロージャは導入必至。 オヤジJavaプログラマの「クロージャは苦労じゃ」のネタは既に あるものとして色々なバリエーションが考えられてるからです。 どんなものでもイイが、上のネタを生かすために簡単なものであっては困る事だけは確かだ。 270 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 02:25:33 ] クロージャの正しい概念ってどんなの？ ECMAScriptだとthis参照を遅延生成メソッド内に埋め込むやり方で使ってるよね でもJavaのthisってコンテキスト参照じゃなくてインスタンス参照でしょ？ 271 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 02:44:45 ] XMLリテラルがどういう利点があるかわからないんだけど。 272 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 03:11:42 ] >>271 構造を持ったデータを簡単に作れることじゃないの？ 今までせこせこ、ＬｉｓｔとかＭａｐとか組み合わせてたような奴 273 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 03:28:52 ] アノテーションにxmlリテラルが使えると、外部xmlファイルが必要なくなるのは嬉しいか嬉しくないか微妙。 274 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 08:35:14 ] >>270 foldoc.org/foldoc.cgi?query=closure&action=Search の1かな。 Javaに実装するなら、new Callable() { ... } あたりを楽に書ける シンタックスシュガーとして実装がいいんじゃない。 つまり、ローカル変数はfinalなもののみアクセスできる。 >>36 のようなことがやりたければ、 final int[] sum = { 0 } で切り抜ける。 275 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 20:11:40 ] 使い勝手が悪そう 276 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 04:21:46 ] ヒアドキュメントすら否定するのにXMLリテラルは受け入れるJava厨乙 277 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 05:45:45 ] >>276 受け入れてないよ。だからヒアドキュメント否定するんだろ。 278 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 05:49:46 ] とか言いながら、いざ実装されるとマンセーするのがいつものパターン。 279 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 07:45:12 ] ヒアドキュメントはイラン。 ところで、クロージャーって、単なるシンタックスシュガーじゃなくて、スクリプト言語用のバイトコード拡張を利用する構文じゃないのかな。 280 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 11:05:11 ] >>279 それは激しい・・・ ヒアドキュメントと変わらんじゃないですか スクリプト言語のシンタックスがわからない以上・・・・ 281 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 11:13:26 ] >>279 それはまず無い。スクリプト言語用のバイトコード拡張(invokedynamicだったか)は、 クロージャの実装に使えるようなものじゃない。クロージャが単なる匿名クラスの シンタックスシュガーになるんじゃないだろうというのは同意だが、クロージャは、 別にバイトコードを拡張しなくても、既存のコードの互換性を保った形で追加できるはず。 282 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 11:41:58 ] invokedynamic(JSR292)は、 そもそも動的メソッド呼び出しだけだから、 Funarg問題を解決してくれるようなもんじゃないしね。 # Hotswappingの方向で進んでいるからslot参照も付くんだろうが。> JSR292 どういう実装するかよりも、どういう仕様になるかの方が… たぶん、inner anonymous classの参照しているlocal変数、実引数、 例外処理ハンドラ引数がfinalでなければいけないという制約が closureの場合は外れるかどうか。 Inner anonymous classを使った実装になるのは確実でしょ? 後はsyntax sugerでしょうね。 Closure出来たら、コレクションも新しくしないとねw 283 名前：デフォルトの名無しさん [2006/06/07(水) 11:45:10 ] >>280 三行とも意味がわからん…w Groovyの文法は既に定義されているし 284 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:21:26 ] >>282 281だが、 > たぶん、inner anonymous classの参照しているlocal変数、実引数、 > 例外処理ハンドラ引数がfinalでなければいけないという制約が > closureの場合は外れるかどうか。 外れると思うなあ。じゃなきゃ、セマンティクスとしては 今までとほとんど変わらないんだから、わざわざクロージャ を追加するなんて言い方はしないでしょ。あと、細かいが 実引数は仮引数の間違いでは？ > Inner anonymous classを使った実装になるのは確実でしょ? > 後はsyntax sugerでしょうね。 実装としては、Inner anonymous classを使うのに近いものに なるだろうが、仕様としては単なるInner anonymous classの シンタックスシュガーになるってことは無いと思う。 285 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:35:22 ] >>261 なにも考えずに下手に導入するとC#やC++の二の舞となるぞ。 どうしてもそういう機能が欲しければ C++やC#で実装して貰うように頼むか自分で実装するという手もありだな 286 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:41:34 ] ああ、実引数の間違いね。 Closureを実装するにあたって、 JVMの仕様を変えるという話は出てきてないから、 ほとんどsyntax sugarみたいなもんなはずだけどね。 というかinner anonymous classがほとんどclosureみたいなもんだし。 finalが外れるとしても、primitive typeの扱いはどうするのか… 287 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:43:31 ] >>285 つーかクロージャができる今となっては>>268でいいでしょ。 拡張forは黒歴史だ。 288 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:51:02 ] >>286 JVMの仕様を変えないでも、「本物の」クロージャは実装できるよ。 あと、キャプチャされる変数がprimitive typeかどうかは、クロージャ 実装するにあたっては、特に関係無いはずだけど、何か問題ある？ 289 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 13:10:14 ] outer classのslotは、 closureに埋め込んだouter class instansの thisを介して参照すれば書き換え可能だけど、 引数はちょっと面倒じゃない? > primitive Method内でclosureが使われる時、 first class closureが外に持ち運び出されれて使われる時、 複数のclosureからprimitive typeが参照される時の扱いなど。 まあコンパイラが頑張れない問題ではないけれど。 そういうprimitive typeは、 別のinner anonymous classでwrappingすればいいんだから。 290 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 13:38:10 ] ローカル変数も基本型だとスタックフレームにあるから、 オブジェクトでラップしとかないといけないよね。 外に持ち出して複数のクロージャから参照されるかもしれないから。 291 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:17:14 ] >>289 それは、クロージャからouter classのフィールドを参照しているか outer scopeのローカル変数を参照するかによる違いであって、 primitive typeかどうかは関係無いのでは？クロージャから outer scopeのローカル変数を参照可能で、かつ、クロージャから その変数が変更可能なようにする場合、基本型かどうかに関わらず、 オブジェクトでラップする必要が生じると思うんだが。 292 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:54:33 ] >>283 あのースクリプト言語ってGroovyだけじゃないんですが・・・ スクリプト言語への対応って言語の定義はされてなくて、APIの定義なんですよ。 おそらくそこを勘違いされていますよね？ 今あるスクリプト言語だけじゃなくて将来出てくる言語もこのAPIに沿ってライブラリを 用意すれば使えるっていうフレームワークです。 293 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:57:25 ] 今までずっとコンパイル言語はデリゲート、スクリプトはクロージャって漠然と思ってたけど もしかしてもっと高尚な概念だったのか？ｗ 294 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:04:53 ] スコープがどこにあるかで変わるような気もするが デリゲートっていうのはクロージャーよりもっと大きな範囲を表すことばじゃないか？ 295 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:05:00 ] >>293 別に高尚というほどのものではないが、ある言語がコンパイル言語かスクリプト言語 かどうかと(この区別の仕方も問題大有りだがそれは置いとく)、その言語がクロージャ を持っているかどうかは全く関係が無いことは確か。あと、デリゲートってたぶんC#の デリゲートのことを言ってると思うんだが、あれはMS用語であって、C#のあの機能に 対する用語としては全く一般的じゃない。 296 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:09:16 ] D言語もdelegateだろ？そのうち次世代標準になると思うが 297 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:30:15 ] >>296 逆に言えばC#,Dしか無いんだと思うが。しかも、時系列からして、D言語で delegateって呼んでるのは、C#での呼称をまねたんだろう。次世代標準に なるかは知らないけど、delegateはあまりセンスがいい機能だとは思えん。 298 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 21:55:27 ] delegateといえばそんな名のproxyを思い出すのはもうおじちゃん世代なんでしょうか・・・ 299 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 22:47:03 ] >>291 outer scopeのローカル変数を参照している場合、 クロージャオブジェクトとは別のオブジェクトでさらにラップする必要があるでしょ。 複数のクロージャから共有される場合は必ず。 基本型じゃなければ、実はポインタが指しているわけだから、 複数のクロージャオブジェクトから共有するのは自然にできるけれど。 300 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 22:49:22 ] プログラミング言語で、"delegate"を最初に聞いたのは"actor"かな。 301 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 23:20:27 ] >>299 > outer scopeのローカル変数を参照している場合、 > クロージャオブジェクトとは別のオブジェクトでさらにラップする必要があるでしょ。 > 複数のクロージャから共有される場合は必ず。 これは特に異論を言ったつもりは無い。というか、クロージャのセマンティクスを 考えれば、至極当然だわな。 > 基本型じゃなければ、実はポインタが指しているわけだから、 > 複数のクロージャオブジェクトから共有するのは自然にできるけれど。 これはおかしい。クロージャから共有しているのは、ローカル変数その ものであって、変数の値じゃないのだから、ローカル「変数」に対する 変更をクロージャ間で共有するためには、基本型じゃなくても クロージャオブジェクトとは別のオブジェクトでラップする必要があるはず。 302 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 00:12:04 ] 「これはおかしい」以降が分かりません。 ヒープに浮いているオブジェクトを共有していれば十分かと。 303 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 00:38:40 ] >>302 クロージャによって共有されるのは、参照型変数が指している先の オブジェクトじゃなくて(もちろんオブジェクトも共有されるけど)、参照型変数 そのものなので、オブジェクトだけが共有されても変数そのものが共有されないと、 クロージャAで参照型変数aの指している先を変更した後(ここで、オブジェクトの 中身を書き換えるのではないことに注意)、別のクロージャBから同じ変数aを 参照したときに、クロージャAによって変更される前のaの参照先を指している、 というようなことになってしまう。 304 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 06:54:29 ] >>302 >>32 の int sum = 0; list.each(delegate(int i){ sum += i; }); で、sum が java.lang.Integer、クロージャの中が sum = new Integer(sum.intValue() + i); だった場合に、オブジェクト共有じゃだめでしょ。 305 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 08:13:48 ] Javaなら「クロージャいらね、無名クラスで十分」でお願いします。 そしてクロージャが実装されたあかつきには「やはりクロージャは便利だ、すばらしい」でお願いします。 306 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 08:21:39 ] まぁ、使ってみなきゃわからない便利さってのもあるしな 307 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 09:15:16 ] >>305 さすがにクロージャに関しては、無名クラスで十分というのは あり得ない気がする。特に無名クラスを制御構造の抽象化 (内部イテレータなど)に使うのは、冗長過ぎる。複数のメソッドを持っている オブジェクトの場合は、無名クラスの方がいい場合もあるとは思うけど。 308 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 09:16:38 ] >>305 あいかわらず分析力のないｗｗｗ 309 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 12:16:34 ] >>308 別に分析なんてしてないんじゃない？ Java vs ○○系のスレで何度も起きていることを そのまま書いただけでしょ。 310 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 13:29:23 ] は？　意味がわかりませんな あんたのいってることは 311 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 14:37:40 ] 分からないならレスしなくていいよ。 もうちょっと勉強してからどうぞ。 312 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 14:39:51 ] くだらん煽りだ 313 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 14:40:54 ] >>312は>>310宛 314 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 03:16:58 ] ★ネタは分かりやすく★ >>305 は Javaユーザが、Generics導入前には「いらね」と言っていたのに 導入されたら「Genericsネ申」と褒め立てるJavaユーザをクロージャにも当てはめ シニカルな笑いにしたネタ( ´ー｀)y-~~ >>308 は それをむしろJavaユーザの立場から自嘲的に笑いにしたネタ もしくは、単に>>305 の諧謔を理解せず笑ったﾉ(´д｀*) レス >>309 は それをJavaユーザに対する真っ向非難と受け止めた 瞬間湯沸かしレスヽ(`Д´)ﾉ >>310 もう喧嘩と聞いちゃ黙っちゃいられない江戸っ子レス (ﾟ∀ﾟ　)三　三(　ﾟ∀ﾟ) >>311 それに便乗した野次馬 (　´･∀･`)ﾔﾚﾔﾚｰ そんな感じですかね。 315 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 08:43:32 ] >>314 つまり、TemplateイラネをGenericsイラネにいまだに脳内変換してるバカってことか。 だれもGenerics神とか言ってねぇし。 スマソ、>>314自体が、そういうバカを装ったネタだったか。 316 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 10:13:17 ] >>313 いやどうみても>>311宛なんだが 317 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 10:14:20 ] >>315 まさにその通りだ。 たまにこのスレにでてくる馬鹿はC#厨とかＣ言語厨とかの 類だろう 318 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 13:15:36 ] Javaに要望されていたのはC++のtemplateじゃなくて、たんにparameterized typingじゃないの？ その意味でいえば、templateもgenericsも同じようなもんだけど。 あれか、templateイラネといっていた手前、genericsが導入されて引っ込みがつかないから 「genericsはtemplateとは違う、tempalteはいらないけどgenericsはマンセー」 といっしょうけんめい言ってるだけか。 大事なのは型引数がつかえることであって、コード生成なのかただのキャストなのかは あんまり関係ないんだけど。 319 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 13:25:58 ] >>318 だから、導入したときにgenericsって名前にしたんだろ 320 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 23:16:20 ] 俺の記憶じゃ、入れる前はどんなものか決まってなくて C++のtemplate「みたいなの」が入るってことになってて勝手にﾜｲﾜｲやってたと思い 321 名前：C++厨 mailto:sage [2006/06/09(金) 23:32:26 ] C++風なのは入れないというのが暗黙の合意だったと思われ あまり型システムは詳しくないけど、 Modula-3とかOberonの流れを汲むんじゃないの? 多重継承やオペレーターオーバーロードなし。特殊化なんてもちろんない。 322 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 23:54:27 ] タイプセーフenumパターンによるenumの実装は俺からしてみれば懸命だったと思うけど ifよりswitchだみたいな風潮がまだあるのか、余り普及して内容に思える 323 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 00:05:13 ] タイプセーフenumの実現も可変長引数の実現も拡張forの実現も みなGenericsのお陰で可能になったことなんだよ。 Genericsを導入するまでこれら三つを導入するわけにはいかなかった。 324 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 00:06:11 ] >>322 どういうこと？ enumはswitchでかけるし 325 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 03:17:28 ] 次世代Javaスレなのに5.0で導入された機能の話ばっかりでつまらんので、 投下してみる。 JavaにContinuation（継続）機構は必要か？ blogs.sun.com/roller/page/gbracha?entry=will_continuations_continue 俺はあんまり良く知らないんだけど、SchemeとかRubyにはContinuationという 機能がある。これは言うなれば、メソッドを呼び出す時に「おまえ、自分の処理 が終わったらこれを呼べよな」とクロージャを渡してしまう感じだろうか。 もちろんクロージャは（ちょっと前に話題に出てたけど）その時のスタック状態 さえも保持してるので（スコープから外れても、クロージャ内ではまだローカル 変数にアクセスできる、とか）、一種のlongjumpとして働くってことですな。 （というか、そこまでしか分からんかった....） リターン値を見てから処理を決めて....という処理が不要になって、プログラムは シーケンシャルにどんどん突き進めるという利点と、呼び出し元じゃなくても一気に 復帰できる上に、その時のスタック状態まで復元してしまうという、いわば「スタック フレームごとあとで使うから保存しちゃえ」という強力な機能なんだってな。 なんだかContinuation-based Web Serverとかいうものもあるらしい。 で、この機能がJVM（JavaじゃなくてJVMだよ）に必要かどうかという議論。 リンク先ブログの人は、「ウェブアプリはAJAXとかで遷移の少ない方向へ移って いってる過渡期で、移行が完了したらContinuation-based Web Serverの利点は 過渡期の遺物になっちゃう可能性があるし、JVMの大改造が必要だしセキュリティ モデルに影響を与えるからイラネ」といってる模様。 いろんなサイト見て、Continuationは便利そうだが、正直分かりにくいし使いどころ が難しい気がするので、俺もｲﾗﾈ、という感じだな。 326 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 03:43:38 ] JVMみたいなスタックマシンには継続は辛い。 欲しい新機能は、switchの代替になるようなパターンマッチング。 ラベルにGOTOするんじゃなく、値を返す奴がいい。 int result = match<Integer>(obj) { 　A : execute(); return 0; 　B : return -1; 　default : return 1; } って感じの。 327 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 06:24:44 ] >>325 細かいところだけど、ちょっとツッコミをば。 > これは言うなれば、メソッドを呼び出す時に「おまえ、自分の処理 > が終わったらこれを呼べよな」とクロージャを渡してしまう感じだろうか。 これは、継続渡しスタイル(Continuation Passing Style)と呼ばれるテクニックで、SchemeとかのContinuation とは違う。SchemeとかRubyにある継続ってのは、call/ccと呼ばれるもので、1引数の関数を引数としてcall/cc を呼び出してあげると、その関数を「call/ccの呼び出しが終わった地点に制御を移動するような関数」を 引数として呼び出してくれるという感じ。Javaっぽい文法で書くと、大体下のような感じになる。 このプログラムっぽいものを実行すると、ABCBCと表示される。 Continuation process() { 　Continuation result = null; 　System.out.print("A"); 　call_cc(new Function(){ 　　public void call(Continuation c){ 　　　result = c; 　　} 　}); 　System.out.print("B"); 　System.out.print("C"); 　return result; } ... first = true; Continuation c = process(); if(first){ first = false; c.jump(); } System.out.println(); 328 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 10:34:32 ] その前にproper tail call optimization可能なVMかな。 329 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 10:57:52 ] >>324 コンパイラがifに展開するんだとさ int&switchによる高速さはenum&switchにはない 330 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 11:15:29 ] >>329 Enum.ordinal() 使ってint型にして switch するだけなんだけど。 この話も Mustang にも Dolphin にも関係ないね。 331 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 11:17:43 ] ん？実装が変わったのか？ 332 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 11:29:36 ] >>329 >>330 俺もifに展開してると思ってた(というか、記憶が正しければ、 1.5のαかβではほんとにifに展開してたはず)のだが、今の実装は 確かにswitchを使うみたいだね。下のコードをコンパイルして、 逆アセンブルしてみたら、確かにEnum.ordinal()を使ってswitchする コードに展開されてた。 public class TestEnum { 　enum AnEnum {A, B, C} 　public static void main(String[] args){ 　　AnEnum a = AnEnum.A; 　　switch(a){ 　　　case A: System.out.println("A"); break; 　　　case B: System.out.println("B"); break; 　　　case C: System.out.println("C"); break; 　　} 　} } 333 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 18:15:07 ] >>332 実際にどう実行されるかは JVM 側のオプションでも変わって来るんじゃなかったっけ? 334 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 18:43:02 ] >>323 >タイプセーフenumの実現も可変長引数の実現も拡張forの実現も >みなGenericsのお陰で可能になったことなんだよ。 なんで？ for (String str: list) { 　... } を for (Iterator $it = list.iterator(); $it.hasNext(); ) { 　String str = (String)$it.next(); 　... } に展開するだけだと思うんだけど、Generics関係なくね？ 335 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 18:59:16 ] >>324 おまえはtype safeという意味がわからんのか？ 336 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 18:59:49 ] >>320 おれの記憶だとparameterised typingが希望されてて、その例としてC++のテンプレートが挙げられていた。 C++のテンプレートそのままが欲しいやつっていたのかな。欲しかったのはあくまで型引数がつかえることじゃない？ でも昔はGenericsとかGeneric Programmingという言葉はあまり浸透してなかったから、 話としては「テンプレートみたいなのが欲しい」という表現がよく使われていた。 つまりC++のテンプレートが欲しいんじゃなくて、型引数が欲しかったということ。 だから >>172 >いっておくがC++のtemplateとJavaのgenericsとはまったく別もんだよ。 のようなのには、なんというか話がずれてるように思える。 どっちもparameterized typingなんだからおんなじじゃん？実現方法を問題にしてるんじゃないんだよ。 C++のtemplateは否定してJavaのgenericsは肯定してるやつらって。 まあいつものことか。 337 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:12:04 ] >>336 templateを否定してgenericsを肯定してるやつらは template固有の話を問題にしているんだから、 >>336と話が合うはずがないよ。 とｵﾓﾀ。 338 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:15:50 ] >>336 実現方法を問題にしてたんだよ。 339 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:18:29 ] 6.0って構文に関するなんかって変わるっけ？ 5.0と7の間にあるバージョンだから、印象が薄すぎて・・・ 340 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:23:50 ] 5と7の間だとなぜ薄いのかよく分からない 341 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:33:15 ] そらおまえ、GenericsだのXMLリテラルだのキモイ仕様てんこもりじゃないか 342 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:37:36 ] >>335 流れおかしくないか？ 343 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:44:29 ] >>340 5と7は変更が大きいからね。 6はもともと5.1になる予定だったわけだし。 344 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:55:18 ] 5.0は言語仕様の変更は大きいけどAPI的に1.4とくらべてたいした進化はない せいぜいコンカレントまわりくらい ６は結構大きい変更が多いので楽しみ 中でもSwingの大規模修正はびっくりなくらいでは？ 345 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:57:32 ] あのバタ臭い見た目は何とかして欲しいけどな。 346 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 20:22:20 ] デフォルトのLAFはSystemLAFでいいようなきがするな 347 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 20:22:49 ] お前はバタ子さんに恨みでもあるのか 348 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 23:06:59 ] >>344 Swingの大規模修正ってどんなの？ あんまり詳しくないので純粋に聞いてみる。 最近Swingに興味を持ったもので.... 349 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 23:50:35 ] >>334,335 foreachに関してはともかくtype safe enumは Genericsのおかげで「簡単になった」。 タイプセーフの実装は、自分で色々書けば出来たよ。 Effective Javaとか読んでみないか？ 350 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 23:53:57 ] >>348 えーっと、漏れは>>344じゃなくて何が大きいか何とも言えないが、 個人的に助かってるのは ・GroupLayoutの搭載 ・WindowsLAFの改善 ・サブピクセルAAレンダリング あたりかな？中では最適化がかなりゴロゴリありそうだけどよくしらない。 351 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:05:12 ] >>349 type safe enumを定義するのに、Genericsはほとんど使わないわけだが・・・。 352 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:06:10 ] enum A{ ONE, TWO, THREE} のどこでGenericsがいるのだろうか。 353 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:19:01 ] >>351 >>352 Java 5.0のAPIドキュメント見ればわかるけど、列挙型の基底クラスである java.lang.Enumの定義自体にGenericsが使われているよ。 354 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:23:07 ] >>353 Effective Javaのtypesafe enumの実装みたことあるのか? 355 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:37:25 ] >>350 一番大きいのはAWTスレッドがとまっていてもウインドウが描画されることかと あとはJava2DでOpenGLパイプラインがLinux系でデフォになるようでクライアント分野も DirectX使ってるWindowsに速度的に追いつくかなと ただ、5.0のOpenGLサポート見てると非常に期待が出来ないのだけれども JOGL使ってるなら大丈夫かな つーかJOGL標準APIにしてください >>354 そういうこといってるわけじゃないだろ？たぶん

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef