[Java SE 7] 次世代Javaの動向 6 [dolphin]

1 名前：デフォルトの名無しさん [2008/01/03(木) 12:29:37 ] 前スレ [Java SE 7] 次世代Javaの動向 5 [dolphin] pc11.2ch.net/test/read.cgi/tech/1178925915 [mustang/Java SE 6] 次世代Javaの動向 4 [dolphin] pc11.2ch.net/test/read.cgi/tech/1163986696/ [mustang] 次世代Javaの動向 3 [dolphin] pc8.2ch.net/test/read.cgi/tech/1157227790/ 次世代Javaの動向　２ pc8.2ch.net/test/read.cgi/tech/1147881822/ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 552 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 12:06:59 ] クロージャーよりもやっつけで盛り込んだ既存のライブラリ仕様を洗練させて欲しいんだが。 553 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 12:34:23 ] >>551 BGGA v0.5にはない。 554 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 12:34:44 ] 洗練って・・・ 下位互換考えるともう変更できんだろ・・ 555 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 12:37:22 ] >>551 それだと単なるキャストだね。 argがクラス名と変数名/フィールド名で重複してるけど。 556 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 12:39:02 ] >>552 openjdkあたりにパッチ送れば？ acceptされるとは限らんけど。 557 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 12:43:30 ] というか勝手にクラスライブラリ作ればいい。 将来採用されることもありうる。 558 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 13:50:47 ] 必要になれば、Cのtypedefみたいなのでもっとパワーアップしてるのがサポートされるんじゃないか。 タイプ量が多いとかはエイリアスで解決できるわけで、クロージャの言語仕様とは全く関係ない。 といいつつもJavaではtypedefみたいのは永遠とサポートされないと思うけど。 559 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 14:21:24 ] typedefとマクロはないだろうな 560 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 15:14:22 ] JavaFX はどうなったのさ。 561 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 16:00:16 ] >>558 ヘッダファイルを使うC言語と違って、 Javaのコンパイル単位はtypedefと相性悪いでしょ。 publicクラス毎に、何回も同じtypedefを書く必要出てくるし。 あと、typedef入れるより型推論が入った方が嬉しいぞ。 562 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 17:09:38 ] Cのtypedefのパワーアップとして考えられるのは、文字通りtype definedのこと。 型推論と似てるけど、型推論は動的にやるでしょｗ もしあるなら、typedefは静的におこなわれる、型(class)別名で、 変数のようにスコープを持つとかなら、 CやC++ templeteのようにバグとか追跡不可能で エラーメッセージも意味不明にまでなったりしないと思う。 だから、やっぱり長いしタイプ量が変わんないじゃんというのは分かるけど、 タイプ量が多いのとクロージャとは関係ない。 563 名前：デフォルトの名無しさん [2008/03/12(水) 17:13:03 ] 今やるならアノテーションになるけど、 結局はtypedefやりたいならアノテーションつかってツール作って自分でやってくれよってなるんじゃないか。 564 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 17:16:42 ] Adaのtypedefならいいわけか 565 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 17:56:30 ] typedefというよりも、別名（エイリアス）ってのがあればいいってわけだ 566 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 18:25:48 ] >>562 タイプ量が多いのとクロージャは関係ないよ。 タイプ量が多いと builderパターン+クロージャで リスナを生成するのが面倒くさいってだけで。 それに別名定義できても、C言語のヘッダファイルみたいなものがないと それほど便利にはならないっしょ。それよりは型推論の方がいいって事。 型推論も別名定義も両方あってもいいけどさ。 567 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 18:35:57 ] そーいや、>>45には type aliasingあるけど、これも続報ないからどーなってんのかわからんね。 もっとも、これは generics でバカみたいに長くなった型名を短くてわかりやすいものにするのが 主な目的っぽいから、>>550 みたいに generics使ってない上に、 MouseListenerBuilder やら setMouseClickled やら MouseEvent やらの 個々の識別子は長すぎて読み易さを低下させてる、ってわけでもないのに 使うようなモンでもねーと思うが。 568 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 18:47:24 ] もういっそプリプロセッサがあれば良いんじゃね？ 569 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 19:22:09 ] >>567 >>550ならtype aliasingいらんだろ。 元から MouseListenerBuilder やら setMouseClicked みたいな名前使わなけりゃいいんだし。 っても、別名使うにしろ、元のから短い名前で定義するにしろ 可読性とのトレードがあるから短い名前考えるのも面倒だわな。 どっちかっつーと、>>116みたいな引数の型推論入れたほうが楽だしタイプ量減る。 builderパターン + クロージャ + 短い名前： addMouseListener(new MLB().sMC({MouseEvent e => System.out.println("clicked"); })); builderパターン + クロージャ + >>116みたいな引数の型推論： addMouseListener(new MouseListenerBuilder().setMouseClicked({ e => System.out.println("clicked"); })); 570 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 19:24:45 ] > addMouseListener(new MLB().sMC({MouseEvent e => System.out.println("clicked"); })); なにこれ 571 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 19:30:27 ] >>570 よーするに、可読性落とさないような名前が思いつかないなら >>550のタイプ量は妥当だって事。 572 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 21:31:24 ] そもそも、タイプ量だけなら >>543 使って onMouseClicked({MouseEvent e => System.out.println("clicked"); }); で良いんだし。もしくは >>543 と control invocation syntax 使って onMouseClicked(MouseEvent e){ System.out.println("clicked"); } 573 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 21:42:20 ] 別にクロージャーが入っても何か新しいことが出来るようになったり 下らないミスが減ったりするわけじゃないんでしょ。拡張 for 並みに どうでもいいんだけど。 574 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 21:43:13 ] >>572 エイリアスやらマクロやらプリプロセッサやら出してくるぐらいなら、そっちのがいいね 575 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 22:01:29 ] 拡張forは便利だろ。 いちいちインデクサなんて書いてられるか可読性も落ちる。 576 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 22:04:29 ] インデクサ？ Iterator の間違いじゃね？ 577 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 22:10:25 ] javax書き換えられないようなsuperpackageはいらない、Sunの失態が無いなら良いけど 578 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:00:42 ] ↑ん？どういうこと？ 579 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:01:12 ] >>575 C#に洗脳されすぎｗ 580 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:03:18 ] クラスとかメソッド名が長いってだけなら、ビルダークラスとかを継承してオーバーライドして自分で短い名前にしてくれよ。 それぐらい頭使え。 581 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:12:34 ] void hoge(a){actionPerformed(a);] で、短いメソッド名で実装して、それを呼び出すことね。 582 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:26:28 ] indexerって普通の英語なんだが。 583 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:30:00 ] Javaじゃそんな言葉使わんしここ日本。 584 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:31:02 ] 普通の英語って事は「索引を作る人」って意味で使ってるとか？ 585 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:02:39 ] >>583 お前は日本語でプログラム書くのか？ 586 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:16:46 ] 演算子オーバーロードが言語仕様にあれば Javaでもインデクサって普通に呼ぶだろうね。 Javaもinterface経由で演算子オーバーロードに対応したらいいのに。 AppendableとかCalculateableみたく、目的を明示すれば設計者も馬鹿しないでしょ。 587 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:21:01 ] 演算子オーバーロードは絶対にサポートしないといってたけど。 588 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:28:40 ] >>585 いやいや、言いたいのは話をわざわざ分かりにくくするために英語にする必要はないだろうということ。 589 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:33:24 ] C#ちゃんはいいかげんに巣に帰れよ 590 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 02:05:45 ] インデクサくらい理解してやってくれ。 ループ抽象(拡張for) コントロール・インヴォケイション・シンタックス は過激に便利ですよ。>>539のp4-6見てください。 プログラム構造がかなりすっきりまとまります。 プログラム内でのコードの共通化も進みますし。 591 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 03:43:59 ] ↑もうこなくていいから。死んでくれ 592 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 06:40:12 ] 病的な過剰反応だな。明らかにネットに向いてない。 593 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 14:00:38 ] >>592 おまえも 594 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 21:56:17 ] >>561 別に相性は悪く無いと思う 以下のような感じでstatic importでtypedefを取り込めるような仕様にしておけば 問題無し -- A.java -- package a; public class Alias { type FileName = String } -- B.java -- import a.Alias._; public class B { public static java.io.RandomAccessFile open(FileName name) { .... } } 595 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 22:49:58 ] >>594 それをやるには static import とは別の仕組みが必要になるし、 どうせやるなら class Alias みたいなものをヘッダファイルモドキとして使うのは間抜けすぎる。 596 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 23:59:35 ] >>595 それ言っちゃおしまいでしょ。 java.lang.Math とか java.util.Collections とか、 クラス外にメソッド置いとけるんならクラス外に置きたいようなのは標準APIにも多いし。 Java でやるなら >>594 みたいなやり方しかないと思うけどね。 597 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 00:01:58 ] >>562 > 型推論と似てるけど、型推論は動的にやるでしょｗ MLなどの型推論はコンパイル時に静的にやるよ。 動的だったら、型を推論するまでもなくチェックすればいい。 >>567が言っているような、 generics使って汎用に書かれたクラスに、 具体的なクラスを与えて、新たなクラスとしてpublicにする、 って機能は必須だと思う。 ただconcept(C++), type class(haskell)のような形の方が より汎用でスマートだと思う。単なるエイリアスじゃなくて 両クラスのグルーとなるコードも加えられるし。 598 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 00:05:28 ] >>596 クラス外メソッド定義とクラスエイリアスは別件。 599 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 00:15:29 ] >>598 クラス外メソッド定義したいって言ってるんじゃなくて 言語仕様が許すなら必ずしもクラス内に置く必要ないエイリアスやメソッドを クラス内に置かなきゃいけないのは等しくアレだって事 600 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 02:39:52 ] アノテーションでいいよ。機能的には違うけど、本質的に同じだし。 601 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 03:01:16 ] クロージャーなんて既存機能で十分まかなえるものの焼き直しなんかより もっと AOP 的設計が出来るようなアプローチしろよ。インスタンスフィールドへの アクセスもトラップできるようにすればそもそもプロパティ拡張もいらんだろが。 602 名前：デフォルトの名無しさん [2008/03/14(金) 03:44:37 ] クロージャで演算子オーバーロードもとラップできるといいけどな 603 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 05:49:16 ] > インスタンスフィールドへのアクセスもトラップできるようにすれば フィールドアクセスがめちゃくちゃ遅くなりそうだな 604 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 06:29:16 ] final 宣言されてない getter/setter と同等にできるだろ。めちゃくちゃの根拠が不明。 まぁプロパティアクセスに関しては「後で」「静的に」「他のソースを修正せずに」アクセサを 追加できれば十分だが。 605 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 06:51:54 ] また変な奴が常任してしまったな。 606 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 06:54:17 ] ＪＳ乙 607 名前：デフォルトの名無しさん [2008/03/14(金) 07:11:52 ] C#厨房よりはましｗ 608 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 07:28:45 ] というかおまえ誰だよ 609 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 07:33:04 ] 俺ビルジョイ 610 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 07:58:33 ] ＪＳじゃイニシャル違うじゃんかよ 611 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 10:58:17 ] >>604 そか？ 隠蔽されたフィールドに対するアクセスとかも考えたら プロパティモドキじゃ対応できないし馬鹿みたいにでかい仕組みが必要になると思うが。 612 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 12:18:31 ] JKが女子高生なんだからJSは・・・ 613 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 12:22:35 ] 専門学校生だよね 614 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 12:30:48 ] >>611 それだけなら何とかなると思うが…… もっとも、リフレクション対応までして「インスタンスフィールドアクセスのトラップ」 できるようにするより他の事にエネルギー使って欲しいぞ。 615 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 15:49:59 ] J 常識的に S ｾｯｸﾙして 616 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 16:03:51 ] >>611 現時点でも少なくともリフレクション程度は確保できる。 まぁフィールドアクセスはそれも包含できるという意味で引き合いに出しただけで本意は別。 ゴリゴリ書くしかなかったのを簡素化したいのはもっともだが、なら無名内部クラスより DI の標準様式一つでも考慮しろと。 617 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 16:14:40 ] > DI の標準様式一つでも考慮しろと。 ？ 618 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 01:41:01 ] あれ？JFileChooserが遅いバグって6u5までのどこかで修正入った？ 619 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 10:17:10 ] >>541 つーか選択肢は二つくらい(?)あって 　・クロージャから抜けるのみ ・・ >>540のコードなら、doSomething() が実行されないだけで for each は続く 　・for each の置かれているメソッドから抜ける 「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら 前者が選ばれるだろうなと思ってさ。 620 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 10:19:34 ] >>619 > 「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら 違う。 621 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 10:32:19 ] 匿名クラスの構文糖って言いたかったんかな 622 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 11:45:56 ] クロージャのreturn周りはどうなるのかホントわかんないな。 ECMAScript風になるのか、ruby風になるのか。 623 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 11:54:42 ] C#風に、内容に expression しか書けないクロージャ（ラムダ式）と、 statements が書けるクロージャの2種類作るってのもアリだと思うんだけど。 624 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 11:54:49 ] どっちでもない 625 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 12:41:25 ] ruby風はありえないだろ 何がどこに抜けるんだかバージョンによって変わるだなんて 626 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 13:29:50 ] returnで脱出する最外レベルはメソッドであって、 クロージャやブロックではない。 詳しくは www.javac.info/closures-v05.html を読め。 627 名前：デフォルトの名無しさん mailto:sage [2008/03/31(月) 04:07:09 ] Listenerを登録するという設計自体がクロージャと相性が悪いわけか なんでこんな設計にしたんだ 628 名前：デフォルトの名無しさん mailto:sage [2008/03/31(月) 04:15:55 ] 他に手がないからだろ 629 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 08:58:11 ] >>627 てか他に手は無いだろ 630 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 02:03:03 ] >>627 相性が悪いって程でもないと思うが 確かBGGAでは、function typeをListenerに暗黙に変換するための 仕掛けが用意されるんじゃなかったっけか 631 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 09:54:37 ] >>630 ActionListenerみたいにメソッド一個しか無い場合は変換できるけど、 BGGAには、MouseListenerみたいにメソッドいっぱいある場合の変換の仕掛けはないよ。 named inner methodがあるFCM と比べると、BGGAとXxxListenerは相性悪い。 632 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 10:02:50 ] tronicek.blogspot.com/2008/03/method-references-version-2008-03-17.html method reference だそーです。 method reference に '#' 使うのが平気な感覚もってるのに accessing property に '.' 以外の演算子使うのってダメなんかねぇ…… と思ったり。 633 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 10:50:41 ] listOfArgumentTypesは必要かね? 継承に絡まない型推論はしない主義だから必要になるのかな。 文脈は常に強く型付けされているはずだが。 634 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 10:59:04 ] もう Method の静的解決 (Foo.class みたいな) でええやん。関数ポインタみたく使えりゃええんじゃろ。 635 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 11:00:07 ] static import で listOfArgumentTypes 書けるようにしてくれませんかね？ 636 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 19:35:24 ] >>633 本来なら通常は要らんと思うけど、同名のメソッドがオーバーロードされてる 場合必要になるから、必須にしてるんじゃないかな？ 637 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 19:41:39 ] それは型情報で分かるから。 638 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 20:49:02 ] >>634 ちがうよ。変数スコープが重要 639 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 21:46:47 ] >>637 contravariant な変換許すなら、型情報だけから必ず判るわけじゃないから listOfArgumentTypes 省略しないタイプも必要だと思うぞ。 省略できても良いと思うけど。 640 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 23:01:51 ] >>637 (System.out#println(String)).invoke("Foo") みたいな場合を考えると必要なケースもあるよってこと もちろん、必要じゃないケースもあるから省略はできてもいいと思う もちろん、上のような式を実際に書く必要はないだろうけど、文法上 書けるなら対策は必要になるわけだ 641 名前：デフォルトの名無しさん mailto:sage [2008/04/09(水) 23:28:18 ] そろそろjdk1.7はリリースされるの？ 642 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 00:19:26 ] 来年の始め頃じゃないか 643 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 00:27:41 ] 1.6updateN が出てから 1年ぐらいは必要じゃないかと思うが 644 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 09:45:57 ] なんだ。まだか。 645 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 21:34:28 ] Java7からと思ってたが、Java KernelはUpdate Nから入るのね。 JMFあたりも自動ダウンロードしてくれるならありがたい限りだけどどうだろ。 646 名前：デフォルトの名無しさん mailto:sage [2008/04/18(金) 12:48:24 ] JDK7 build25 download.java.net/jdk7/changes/jdk7-b25.html download.java.net/jdk7/binaries/ 647 名前：デフォルトの名無しさん mailto:sage [2008/04/19(土) 06:58:13 ] クロージャーなんかよりも、入出力ストリームや Lock 使った try-finally 使いまくりのコードを きれいに書ける構文考えてくれよ。synchronized と違和感ないような (これもブロック抜けるときに モニタ開放するし)。 try(Writer out = new FileWriter("foo.txt")){ 　　... } catch(IOException ex){...} ↓みたいな。二重tryでもいいや。 Writer out; try{ 　　out = new FileWriter("foo.txt")){ 　　... } catch(IOException ex){ 　　... } finally{ 　　try{ if(out != null) out.close(); } catch(IOException ex){throw new RuntimeException(ex);} } 648 名前：デフォルトの名無しさん mailto:sage [2008/04/19(土) 08:59:28 ] それは既に入る予定だが? しかもクロージャを使って。 649 名前：デフォルトの名無しさん mailto:sage [2008/04/19(土) 09:30:50 ] >>647 つ control invocation syntax 650 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 14:22:07 ] 次のjava7でクロージャ以外で主要な目玉機能ってなんですか？ 651 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:03:13 ] 俺はダグ・リー先生のjsr166y.forkjoinがどうなるかが最大の関心事 素晴らしすぎ。 652 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:21:19 ] 今度の JavaOne で dolphin の進捗も発表されんじゃね？

---

---

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

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