1 名前:デフォルトの名無しさん [2007/05/12(土) 08:25:15 ] 前スレ [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の動向 2 pc8.2ch.net/test/read.cgi/tech/1147881822/ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/
596 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:16:58 ] public const<String, Boolean> getResult() { return const { "おkwwww", true }; } こんな感じで死にキーワードを流用できないものか
597 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:20:27 ] >>596 それだったら Pair<A, B> で良いじゃん。
598 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:26:16 ] 普通のGenericsは可変長じゃねー
599 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:36:13 ] じゃ、 static <A, B> Pair<A, B> tuple(A a, B b) static <A, B, C> Triple<A, B, C> tuple(A a, B b, C c) static <A, B, C, D> Quadruple<A, B, C, D> tuple(A a, B b, C c, D d) みたいにすれば?
600 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:49:41 ] こらこら。Javaにrefやoutはないでしょ。 尤もCommonsLangあたりにはあっていいクラスだとは思うけど
601 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:52:29 ] ref や out って、どこの話だ?
602 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:52:37 ] 多値よりも Ref<T> のほうがまだ使い勝手が良さそうな気がする。
603 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:53:37 ] ああ、ファクトリメソッドか、俺の勘違い。 >>601 C#
604 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:55:55 ] >>603 いや、レス番の話。 このスレのどこで ref や out の話が出てんのか、と。
605 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:57:38 ] 俺が>>601 をクラス定義と勘違いしただけだって。
606 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:59:21 ] あ、>>599 ね。あかん、おねむの時間っぽい。
607 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:03:13 ] >>599 にも ref や out があるようには見えんが……
608 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:04:09 ] どう勘違いしたのかくらい考えろ馬鹿ちん
609 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:07:16 ] なんだ、勘違いか。なら考えても無駄だな。
610 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:09:24 ] 遅かれ速かれ多値はサポートしてくれるものと思いたい。
611 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:10:54 ] JVM系LLで多値サポートしてたら、そっち使えって話になるんじゃね?
612 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:15:23 ] var rand = new Random(); int n = rand.nextInt(); みたいな書き方も需要あるから、多値もJSRには上がるとは思う。
613 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:17:32 ] bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792 will not be fixed になってる。
614 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:23:36 ] >>612 どうだろね? 型推論ですら、変数宣言時の型指定を省くのは Java 的じゃないってんで G<T> g = new G(); みたいに、初期化子の方のパラメタ型指定を省けるようにしようって 論調の方が強いみたいだけど。今までの G<T> g = factoryOfG(); みたいな型推論とも一貫性あるってのが良いらしい
615 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:28:40 ] G<T> g = new(); みたいなのもどっかで見たな。
616 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:31:31 ] 極力interfaceで受け取れいうてる今までとの親和性の問題もあるし、 今後の拡張はローカルキーワードで行きたいって思惑もあるから 早い段階でサポートするならそっちかもな >>615 みたけど流石にそれはないw
617 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:42:13 ] varの方はGraphicsEnvironment.getLocalGraphicsEnvironment()とか長すぎるから何とか汁って考えもあったはず
618 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:47:32 ] >>617 つ static import
619 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:49:48 ] staticじゃなきゃ役にたたねーけどね
620 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:52:21 ] メソッド名が長いのはメソッド名のalias導入とかせんと解決せんのでは?
621 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:54:22 ] 関係ないけど、メソッド名ってたしか長さ制限あったよね
622 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:00:53 ] static importはユーティリティメソッドに 沢山依存してる状態じゃないと返って面倒なだけ
623 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:05:31 ] 名前空間が汚れる。
624 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:06:13 ] まあ、結局のところD言語はvarで解決としたみたいだからJavaもそうなるよ。 プロパティ問題も馬鹿なことやらないで、素直にC#風にしたしね。
625 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:26:52 ] > プロパティ問題も馬鹿なことやらないで、素直にC#風にした ソースは?
626 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 23:43:33 ] >>590 Common Lisp, Scheme(R5RSから) (define (foo) (values 1 2)) (set!-values x y (foo)) (set!-values q r (quotient&remainder 10 3)) スタックフレームの返値を格納するスロットが一つ増えるだけだから、 tupleやlistやarrayを箱にする方法より性能がいい。
627 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:01:39 ] >スタックフレームの返値を格納するスロットが一つ増えるだけだから、 それやると VM の変更が必要にならんか? > tupleやlistやarrayを箱にする方法より性能がいい。 その辺の性能あげるためにエスケープ解析とか頑張ってるんじゃね?
628 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:02:35 ] >>627 VMの変更っつーか、VM仕様の変更じゃね?
629 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:07:16 ] >>625 docs.google.com/View?docid=dfhbvdfw_1f7mzf2 これの事じゃね? でも、これbeansのプロパティと互換性ないし、 フィールドとプロパティの名前がかぶった場合どうなるかって部分も甘いような。
630 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 12:14:51 ] 多値はいつか実現して欲しいね。 引数は0個以上なのに、結果は0か1に制限されているのは不便。 >>589 他の言語で使うと癖になるから、粘着的なw要望が続くんだと思う。
631 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 12:20:52 ] >>630 なんつーか、Perlとかで初めてsplitの結果を複数の変数に まとめて入れる表現見たとき便利だと思ったわけで、 こういうのって、返値は配列として扱ってるじゃない。 配列の返値を、各変数に代入するシンタックス糖分があればいいんじゃないかな?
632 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 13:34:05 ] > スタックフレームの返値を格納するスロットが一つ増えるだけ > 配列の返値を、各変数に代入するシンタックス糖分があればいい この二つって全然別の要求なわけで……
633 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 13:35:18 ] >>630 粘着的な要望する奴は口だけ動かして手を動かさんからなぁ……
634 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:09:07 ] >>632 多値って一口に言っても、考えてる事が微妙に違うからなぁ……
635 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:49:27 ] とりあえず配列でやっておけばいいんじゃないの?
636 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:52:17 ] >>635 Object[]を使えばいいじゃんって意味?その場合、複数種類の型を内包する配列を扱うことになるから、 言語的なサポートが欲しいって言ってるんじゃない?
637 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:53:20 ] >>633 このスレに要望出しても意味ねえんだけどな
638 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:54:47 ] 型の問題があるなら、引数のほうに値をうけとる配列として渡すとかね。
639 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:58:05 ] >>637 要望だした時点で気持ちよくなってんじゃないかと。 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね?
640 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:48:10 ] ゆとりのやつって、直接的な効果がなければ意味ねぇとかよく言うよね。 間接的な効果を想像できないんだよね。
641 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:53:01 ] あるあるw ちょっとたとえを出して、それを否定できただけで、全てを否定w
642 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:53:48 ] 間接的な効果に期待(するだけ)しかできないんだったら > 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね? って評価は正しいような。
643 名前:デフォルトの名無しさん mailto:sage [2007/09/17(月) 17:26:43 ] はいはい、ここは次世代Javaのスレですよっと JSR-310 に generics版なるものが出来ていた。 https://jsr-310.dev.java.net/nonav/generics/index.html https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=726 > The basic theory is to define a class for each of the basic concepts - > Day, Month, Year, Hour, Second etc, and then utilise those in other > ways. These are TimePart subclasses. > > Instead of having a dedicated Seconds class that holds only seconds, > there is a single TimeAmount class that is generified: > > Standard design: > Seconds s = seconds(3); > Generics design: > TimeAmount<Second> s = seconds(3); > > Similarly, the field classes such as DayOfMonth are removed with a > single generified TimeField class: > > Standard design: > DayOfMonth dom = dayOfMonth(3); > Generics design: > TimeField<Day, Month> dom = dayOfMonth(3); 個人的に generics版にするなら var dom = dayOfMonth(3); タイプの型推論が欲しいような。
644 名前:デフォルトの名無しさん [2007/09/17(月) 20:18:05 ] blogs.wankuma.com/kacchan6/archive/2007/09/17/96592.aspx
645 名前:デフォルトの名無しさん mailto:sage [2007/09/18(火) 08:41:40 ] generics版は、入力めんどすぎだな
646 名前:デフォルトの名無しさん mailto:sage [2007/09/18(火) 16:45:33 ] ドキュメント簡潔で理解しやすいしこっちのほうが好きなのは俺だけか それはそうと9月の第三月曜日とか毎月第五土曜日(と、第五土曜日が存在するかチェックする方法)とか どうやって入力するんだろう? この程度のことがいちいち煩雑なのは嫌なんだけど。 曜日指定できそうなCalenderDayのDayOfWeekは引数がなぜかint型だし。 曜日関係はまだまだこれからなのかね?
647 名前:デフォルトの名無しさん mailto:sage [2007/09/18(火) 20:37:07 ] あれだ。 カレンダー用のXPathみたいなの作って W3C標準にすればいいんじゃね?
648 名前:デフォルトの名無しさん mailto:sage [2007/09/18(火) 21:04:02 ] CQL CalendarQueryLanguage ばばーん >>647 がただ今鋭意作成中です
649 名前:デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:12:45 ] >>647 Structured Calendar And Time Markup Language 略してSCATML。それのAPIがSCATMLAPI。
650 名前:デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:19:52 ] 31日や2月29日みたいなTimeFieldやTimeViewって カレンダーが背後にあるクラスに受け入れられるまで、意味のあるカレンダーデータかどうかわかんないわけだよな。 ついでにPeriodを加算するみたいな日付計算もできない。 それなら『カレンダーが背後にあるクラス』をインターフェース化しておいたほうがいいんじゃないかと思ったり。 最初はCalendricalがそうかと思ったんだけどなんか違うっぽいな。
651 名前:デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:54:39 ] やっぱCalendricalか。何故かTimeViewやTimeFieldに継承されているけどこれは何かの間違いだな。 weekOfMonthが作れるようになったりTimeField同士を結合してTimeViewを作ったりできねえかな。 そしたら今年の9月の第3月曜日とかでも楽に指定できるのに。難しいのかこれは。
652 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 00:00:02 ] TimeAmountで期間データの変換が相互に可能になってるっぽいが Second〜DayはともかくDay〜Foreverのデータはカレンダーないと変換できないような。 いちいちUnsupportedOperationException投げるつもりかいな
653 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 02:32:47 ] こんな感じで書けないかな static import javax.time.Moments.* ... TimeView<Day,Year> leapyearday = build(MonthOfYear(2), dayOfMonth(29)); CarenderYear year = now().currentYear(); List<CalenderDay> lyds = new ArrayList<CalenderDay>(); for(int i = 0; i < 10; i++){ CarenderDay tmp = CalenderDay(year.plus(i), leapyearday); if(!tmp.wasRolledGenerate()) lyds.add(tmp); }
654 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 02:54:46 ] >javax.time.Moments.* パッケージ名だけ見たらとてつもなく抽象的すぎて何に使って良いかわかりづらいな。
655 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 03:17:56 ] TimeUtilsとかの方がいいよな。常識的に考えて。 そのうち変わると思うが
656 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 11:16:37 ] >>654 time.Momentsってそんなにわかりにくいかな?
657 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 13:15:14 ] 個人的にクラス名変えるならこんな感じ 時刻系 TimeView>TimeExpression:時刻表現 Calendrical>ScaledTime:カレンダー評価済み時刻表現 TimeField>TimeField:即値時刻表現 期間系 Period>Period:期間 TimeAmount>PeriodField:即値期間 単位系 TimePart>Unit:単位 その他 Moments>TimeUtils:ユーティリティクラス うーん、イマイチ。
658 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 16:48:46 ] クラス名・変数名に迷ったら書き込むスレ。Part10 ttp://pc11.2ch.net/test/read.cgi/tech/1180146315/ ここにお願いしてみては
659 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 18:46:41 ] >>656 今のクラス名だと高精度の時間取得APIとも取れるし、時系列系APIのフレームワークとも取れる。 名前から想像できる用途が曖昧で冗長といった印象。 名前からすると一見汎用性がありそうだけど、 けど中身はカレンダーAPIの上位API程度の印象も受ける。 そのため、今のカレンダーAPIとの関係も分かりづらい。 そうなると移行や使い分けが難しいかと。 要するに何のために作ったのか分からん、と・・・。
660 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 19:01:06 ] どう見ても完全に置き換えるものとして使うようにできてるだろ。 互換性を意識しないといけない場合以外は全部移行していいようにするんじゃないのか? まだOverViewには入ってないがフォーマッティングやパーシング用のクラスも作るらしいし。
661 名前:デフォルトの名無しさん mailto:sage [2007/09/19(水) 19:22:46 ] java.util.concurrent.TimeUnit も忘れないであげて
662 名前:デフォルトの名無しさん mailto:sage [2007/09/21(金) 13:05:43 ] JSR 277とJSR 291は議論が熱いね。 www.infoq.com/jp/osgi
663 名前:デフォルトの名無しさん mailto:sage [2007/09/22(土) 10:54:13 ] OSGi関係は熱そうだね。 関わってるところ多いし、影響が大きそう
664 名前:デフォルトの名無しさん mailto:sage [2007/09/24(月) 18:48:55 ] JDK7、機能はすごい魅力的なんだが、リリースが一年以上先か・・・。 堅実なのはいいことだけど、もうちょっと早くならんかなあ。
665 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 01:28:48 ] 目玉機能とされてるJSR-277もまだだし Closureに至ってはJSRすらないしなぁ。 これでリリースまでに全部つっこんできたら十分早いと思うが。
666 名前:デフォルトの名無しさん mailto:sage [2007/09/27(木) 22:46:13 ] 業界的にはまだバージョン4が多数だから早い感じもする。
667 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 00:51:19 ] テンプレート(1.5)、クロージャ(1.7)とくれば、最後に来るのは…マクロ!(1.9予定) すべての言語は最後はlispの一部を再実装する事になるのかと思うと、複雑な気分だな。
668 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 01:00:50 ] バージョン4なんかない。
669 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 02:22:08 ] >>668 R4のことだろ?
670 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 04:08:52 ] RhinoR4?ライセンスが・・・w
671 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 10:11:40 ] 最後はevalだな。
672 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 11:10:22 ] OSGiじゃないのか?
673 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 14:32:28 ] JDK7 build21 download.java.net/jdk7/binaries/ download.java.net/jdk7/changes/jdk7-b21.html だって。 ようやくコンパネの縦長が直った。
674 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:06:09 ] OSGiかなにかのプラグイン機構がJava SEに入るまでまだ一年位あるので、 Javaのスクリプトで代わりをできないかと思ったんですが、 次を読むと普通にできそうですね。 (つまりJavaプログラム実行中に動的に実行コードを入れ替えたい。) JavaからRubyスクリプトを実行する codezine.jp/a/article/aid/1647.aspx?p=3 個人的にプラグイン機構の重要度がかなり下がりました。
675 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:14:59 ] 普通にクラスローダを使えばいいだけじゃないの?
676 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:26:11 ] クラスローダは難しい・・・ 昔OSGiを使ってたときですらクラスローダで苦労した。 確か、setContextClassLoader辺りとか頻発した。 (OSSのライブラリでこれが設定できないので、プラグインから使うために ソースを書き換える必要が発生したこともあった。) 記憶が薄れてるけどOSGiが無いとさらに倍以上苦労する感じだったと思う。
677 名前:デフォルトの名無しさん mailto:sage [2007/10/10(水) 02:31:03 ] URLClassLoaderで簡単にJARファイルからクラスを読み込めるから、 プログラム実行中に動的に実行コードを入れ替えるのは簡単だと思うけどな。
678 名前:デフォルトの名無しさん mailto:sage [2007/10/10(水) 08:53:59 ] >>674 Rubyてw Javascript使えよ。最初からSEに入ってんだから。
679 名前:674 mailto:sage [2007/10/10(水) 13:46:54 ] 助言?ありがとうございます。 >>677 setContextClassLoaderは、Jar内のファイルを読むために 基盤とプラグインのJarのClassLoaderを切り替える のに使ってたんだったと思いますが、 URLClassLoaderを使うと簡単にできそうな気がします。 >>678 JRubyは速いと言う記事が目に入ったので 条件反射で調べてみたのですが、 JavaScriptでいいですね。Rubyは殆ど知らないし。
680 名前:674 mailto:sage [2007/10/10(水) 13:49:23 ] ちなみにやりたい事は、 UMLのステートチャート図で状態遷移を定義しXMLを生成する (このエディタは自作する) 実行時はXMLに従って、各状態と遷移時の処理を行う。 基本的に、ステートパターンで実現する。 こんな感じの多目的に使えるフレームワーク作り。 と言う感じで、DIコンテナで普通にできそうですね…。 それが一番早いなw
681 名前:デフォルトの名無しさん mailto:sage [2007/10/10(水) 16:20:30 ] >>677 具体的にどういうコードになるの? クラスローダーは複雑で言ってる事が見えてこない…
682 名前:デフォルトの名無しさん mailto:sage [2007/10/10(水) 16:44:08 ] >> 681 丁度いいページがあったので勝手にリンクさせてもらいます。 ttp://homepage3.nifty.com/satoshis/java/memo.html#extension
683 名前:デフォルトの名無しさん mailto:sage [2007/10/11(木) 03:45:19 ] JRubyは本家と比べて早いって意味だ。 まあ、宗教は自由だぜ!
684 名前:デフォルトの名無しさん mailto:sage [2007/10/11(木) 09:54:50 ] >>682 おお、そういうことか!
685 名前:デフォルトの名無しさん [2007/10/13(土) 23:07:55 ] そろそろクロージャの仕様決まった?情報まだぁ
686 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 23:23:22 ] www.javac.info/ www.javac.info/closures-v05.html www.javac.info/consensus-closures-jsr.html あたりは動いてないね。JCPのJSRのリストにも登録されてないみたいだし。 他の場所では動いてるのかも知らんけど
687 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 23:49:45 ] ああ、いろいろプロポーズはあるみたいだけどそれが採用されそう。
688 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 01:16:57 ] 簡単に読み書きできることが重視されるJavaでは導入が難しいのかも。 クロージャに結びつけた変数に対して破壊的操作を行うプログラムを書いちゃうと、 非常に理解が難しいプログラムになる。と某所で言われていた。
689 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 01:28:27 ] staticメソッドとクロージャを組み合わせて制御文みたいなのを作れるのは面白いと思ったけど フォールスルーしないswitch文みたいなのは無理かね
690 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 02:13:48 ] クロージャ、クロージャ言うけどクロージャ導入しても元々クロージャに書き換えるようなメソッドなら コンパイル時にインライン化されてるだろうから人がクロージャ書く意味ってあるか? JavaScriptも使うからクロージャは大好きだが・・・。
691 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 02:20:41 ] うん、無理っぽいな。できたとしてもがcaseに指定された値が定数かどうかを判別するすべがないから意味ないし String line; while ((line = br.readLine()) != null) みたいなループをfor eachLine(String line : br)みたいには直せそうだ。あんまりいい例じゃないが >>690 コストが低いからクロージャを使うわけじゃないだろ
692 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 03:35:29 ] いいかげんプリプロセッサとはいわんからせめて#ifdefを導入しろよ
693 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 03:46:15 ] >>690 わかりやすいから使うんじゃないのか? いい加減いちいち無名クラスを宣言するのめんどうになってきたよ。
694 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 04:47:24 ] もう関数型のパラダイム全部入れちゃえばいいじゃんw
695 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 05:53:53 ] どうせこうなるんなら最初からいれちゃえばよかったのに
696 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 13:56:40 ] クロージャが、多重継承のようにうまく使えば有用だが弊害もある機能だったらどうするんだ? Javaはハッカー向け言語ではなく一般向け言語なんだし、彼らが誤用しにくい機能であるか検証しなければならない。