08/01/03 12:29:37
前スレ
[Java SE 7] 次世代Javaの動向 5 [dolphin]
ｽﾚﾘﾝｸ(tech板)
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
ｽﾚﾘﾝｸ(tech板)
[mustang] 次世代Javaの動向 3 [dolphin]
ｽﾚﾘﾝｸ(tech板)
次世代Javaの動向 ２
ｽﾚﾘﾝｸ(tech板)
【Java】次世代Java・J2SE1.6の動向【Mustang】
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
08/01/03 12:35:37
三行でなくてもいいので、
最近のJavaはどういう言語的要素を取り入れようとしているのか
簡潔に教えてください。
3:デフォルトの名無しさん
08/01/03 15:21:37
JDK7の大きな機能追加というと、
・クロージャ（ってMSVJ++のDelegateとどう違うのだか俺にはよくわからんのだが）
あとあとなんだっけ。
4:デフォルトの名無しさん
08/01/03 15:39:31
クロージャ追加って決定事項なの？
5:デフォルトの名無しさん
08/01/03 16:18:19
どうなったら「決定事項」なのか定義してくれ
6:デフォルトの名無しさん
08/01/03 16:38:12
>>5 おまえもウザイやっちゃなｗ
クロージャ追加は濃厚ってこと。
7:デフォルトの名無しさん
08/01/03 17:11:43
Duke に隠し子発覚。
8:デフォルトの名無しさん
08/01/03 17:35:27
>>6
総論としてのクロージャ追加に反対な人たちは少数派みたいだし、
クロージャ追加反対論の先頭に立つ人もいないから、
その意味ではクロージャ追加は濃厚。
ただし、各論としては、オレはアイツの提案のあれが気にくわないって感じでもめてる。
だからクロージャでもめたせいで1.7のリリースが遅れるとか
1.7の機能からクロージャが漏れるとかって事態はありうる。
9:デフォルトの名無しさん
08/01/03 18:26:26
例外処理まわりで使いやすくなる予定ってないのかな？
10:デフォルトの名無しさん
08/01/03 18:26:27
遅れるとか、そりゃないだろな。
BGGAだったか、{int a=>a+1;}; でまとまるよ。
その説得ってことだろうｗ
なんなら、ニールのブログに突撃してみたらどうだ？
このスレ的には勇者になれるしw
11:デフォルトの名無しさん
08/01/03 18:30:17
クロージャ
プロパティ
BigDecimalの演算子化
invokedynamic (JVM bytecode)
見た目で感じられて、濃厚なのはこれぐらいかな。
あとアノテーション拡張がどうとか。
12:デフォルトの名無しさん
08/01/03 18:33:25
個人的には
BigIntegerの演算子かも頼む
13:デフォルトの名無しさん
08/01/03 18:38:42
個人的には演算子オーバーロードをいい加減サポートして欲しい。
シンプルさを維持できないとかいう理由でその予定はないらしいが、
だったらString型のシンタックスシュガーもやめろよと思う。
14:デフォルトの名無しさん
08/01/03 18:53:51
>>13
C++とJavaは違うってことだｗ
また鼻息あらいようだなｗｗ
15:デフォルトの名無しさん
08/01/03 18:55:47
>>13
当然英語はできるんですよね？
16:デフォルトの名無しさん
08/01/03 19:02:55
限定的に使えるのと自由勝手に定義できるのじゃ全然違うべよ。
ALL OR NOTHING な発想は思考停止に等しい。
17:デフォルトの名無しさん
08/01/03 19:04:51
演算子オーバーロードはバグの温床
18:デフォルトの名無しさん
08/01/03 19:11:48
演算子オーバーロードが必要な人は大体は行列や複素数程度しか頭にないんだろうけど、
もしサポートしたら、いろいろすごい事になっちゃうよ。
とうか、もう違う言語かよってぐらいｗ
つまり
演算子オーバーロードが必要な人は大体は行列や複素数程度しか頭にないんだろうけど、
歴史的にはCのプリプロセスの悪夢と似てるんじゃないかｗ
19:デフォルトの名無しさん
08/01/03 19:14:07
それが必要なら、なんならリスト志向・関数志向の言語もやってみたら？
20:デフォルトの名無しさん
08/01/03 19:15:02
>>11
そこで出てる中で、仮にもJSRまでいってるのは
invokedynamic の JSR-292 と、
annotations on Java Types の JSR-308 かな。
プロパティは、JSR-303 とか JSR-295 とかあるけど、
構文糖の方は入るのかよくわからんし。
21:デフォルトの名無しさん
08/01/03 19:15:29
>>16
当然英語はできるんですよね？
22:デフォルトの名無しさん
08/01/03 19:18:12
>>20
"a" + "b" + "c"
"a".concat("b").concat("c")
よく使うし、普通は上でしょ。
理屈抜きで、プロパティもこれと同じようなことじゃないか。
23:デフォルトの名無しさん
08/01/03 19:19:14
フォートレス言語？
24:デフォルトの名無しさん
08/01/03 19:21:03
そーいや、Array syntax for collectionsはどーなったんだろ？
あれも演算子オーバーロードっちゃ演算子オーバーロードだよなぁ。
25:デフォルトの名無しさん
08/01/03 19:26:05
>>22
いや、プロパティの構文糖自体は簡単でもソースの互換性とろうとすると複雑なルールになるから面倒なんよ。
あと、beans仕様全体が性善説的な、みんなで守りましょうねって感じのルールなんで
Java言語仕様みたいな性悪説的なルールとして捉えると穴だらけなんで、そこら辺でも話はややこしくなる。
26:デフォルトの名無しさん
08/01/03 19:30:23
クロージャ
プロパティ
BigDecimalの演算子化
invokedynamic (JVM bytecode) ； JVMで複数の(スクリプト)言語サポートのこと
アノテーション・拡張
ジェネリクス
これだけあれば十分と思うけど。
これ以上が必要となる環境にいないしw
ということで演算子オーバーロードとかはもう過去の話ｗ
個人的には複素数も扱いやすいと数値計算・科学分野・学部生でも、
入門・お気軽プログラムできそうなんだけどね(JavaはGUIサポートしてる)。
個人的には、Javaは平面(GUI)を扱えるから複素数を押したい。
でも今はSUNは、デスクトップの方に力を入れて数値科学のほうは全然だしｗ
27:デフォルトの名無しさん
08/01/03 19:32:22
>>25
便利ならいいよ。俺らは策定する方じゃなくて、使うほうだしね。
28:デフォルトの名無しさん
08/01/03 19:33:50
そういやクラスのメソッドとしてではなく純粋な関数が入るかもって話はどうなったんだろ
29:デフォルトの名無しさん
08/01/03 19:36:20
>>27
策定する方も面倒だから簡単にはできねーだろーなっつー話。
プロパティ構文糖のプロトタイプ(?)がkijaroだったかに入ってるけど
あれ旧beansのプロパティと互換性ないでしょ。
30:デフォルトの名無しさん
08/01/03 19:36:58
>>28
function typeはモメてる。
31:デフォルトの名無しさん
08/01/03 19:37:14
>>25
また宗教ですか？
32:デフォルトの名無しさん
08/01/03 19:41:27
まだJDK1.7までは1年以上あるだろ。一回決定すると変更できないから、ちゃんと議論して、ちゃんと煮詰めて欲しい。これについては、納期とか速くしろとかとは別次元の話だろうな。
33:デフォルトの名無しさん
08/01/03 19:44:28
今年中に1.7出そうと思ったら もう1年もないし、
新機能追加を止めて、バグ取りに専念する期間も必要って事を考えたら
現時点でJSRすら出てない機能は相当遅いと思うけどなぁ。
34:デフォルトの名無しさん
08/01/03 20:57:08
演算子オーバーロードは
C++の入出力みたいに副作用を演算子で処理するのは違和感があるな。
Immutableなオブジェクトでないと使えないようにするとか……
35:デフォルトの名無しさん
08/01/03 22:21:45
Javaでの演算子のオーバーロード禁止は、シンプルさ確保が目的ではなくて、プログラマが乱用するのを防ぐために禁止にした。
言語仕様レベルでStringやBigDecimalを特別扱いしてやるのがJavaの回答(言語仕様策定者のみが定義できる)。
Javaの言語仕様はプログラマを信頼しない性悪説に基づいているので、自由にやらせろの人にとってみれば悪の化身のような言語にみえるだろうが、初級プログラマが世の中に多い以上こういう言語も必要だ。
Java と Java(Beta) みたいに言語を２つにして１つは初中級向け言語、１つは初中級者向け言語に機能優先で言語仕様を追加した中上級向け言語のようにしてみると、Javaにあの言語仕様入れろとかいう不満は少なくなるように思う。
36:デフォルトの名無しさん
08/01/03 22:49:26
>>35
それ、Scala使えって言われて終わりになるよーな。
37:デフォルトの名無しさん
08/01/03 23:02:54
Genericが結局1.4に入らなかったみたいに、7には積み残す方向で行くかもな。
38:デフォルトの名無しさん
08/01/03 23:47:11
>>33
知ったことではないけどねｗ
39:デフォルトの名無しさん
08/01/03 23:49:33
>>35
また宗教ですかｗ
分割するまでもなく、そういう人はruby, javascript でやってよ。
JVMでサポートされるし。
思うに君のような宗教家はJava宗教に向いてないだろうと思う
40:デフォルトの名無しさん
08/01/03 23:51:27
馬鹿にするなよ！
>>35は英語バリバリなんだじょ～
41:デフォルトの名無しさん
08/01/04 00:03:51
>>35のようなやつがプロジェクト率いたり仕様書作ったりしたら大変な事になりそうだなｗ考えただけでも恐ろしいｗｗ
42:デフォルトの名無しさん
08/01/04 00:07:14
>>35
当然英語はできるんですよね？
43:デフォルトの名無しさん
08/01/04 00:53:33
35氏の人気に嫉妬
44:デフォルトの名無しさん
08/01/04 02:09:04
>>35の言ってることが特に変だとは思えないけどな。
別の言語として、Javaのような何かが必要とは思わないけど。
45:デフォルトの名無しさん
08/01/04 08:08:11
Java SE 7 wish list
URLﾘﾝｸ(blogs.sun.com)
46:デフォルトの名無しさん
08/01/04 11:51:23
英語はやっぱり面倒じゃじょ～
47:デフォルトの名無しさん
08/01/04 11:55:30
>>35は総突っ込みされてさぞ嬉しいだろうなｗ
48:デフォルトの名無しさん
08/01/04 16:08:56
英語出来なくても誰かが翻訳してくれるし。
49:デフォルトの名無しさん
08/01/04 16:10:22
>>35
はC, C++, C# の分化した歴史を話してるのだろうかと思った。
50:デフォルトの名無しさん
08/01/05 00:29:30
新参です
「当然英語はできるんですよね？」ってどういう経緯で始まったテンプレなんですか？
51:デフォルトの名無しさん
08/01/05 00:37:49
>>50
ｽﾚﾘﾝｸ(tech板:953-番)
52:デフォルトの名無しさん
08/01/05 01:03:32
>>51
さんくすおあらっと
53:デフォルトの名無しさん
08/01/05 10:18:45
英語で会話できるようになるのは、日本人の夢なのです！
54:デフォルトの名無しさん
08/01/05 20:13:52
クロージャでRAIIっぽく書けるらしいね
55:デフォルトの名無しさん
08/01/06 11:34:40
英語だとなんか緊張しちゃうし、別に日本語で十分じゃね？
APIの翻訳もリリースにあわせて出てるし技術書も翻訳でいいよ。
日常でも英語なくても困ってないし英語いらねー
56:デフォルトの名無しさん
08/01/06 12:09:13
>>13
>>35
当然英語はできるんですよね？
57:デフォルトの名無しさん
08/01/06 14:32:02
>>55
だいたいみょうちくりんな日本語だなあ、と思う文書は翻訳版だったことが多い。
58:デフォルトの名無しさん
08/01/07 00:08:39
>>56
粘着してる人つまんないからもういいよ
59:デフォルトの名無しさん
08/01/07 00:16:18
>>58
あたま大丈夫か？
60:デフォルトの名無しさん
08/01/07 00:19:54
>>58
新参乙
61:デフォルトの名無しさん
08/01/07 00:29:51
>>59
当然英語はできるんですよね？
62:デフォルトの名無しさん
08/01/07 00:31:22
粘着だろうと便乗だろうとつまらないことには同意しとく
63:デフォルトの名無しさん
08/01/07 01:08:19
ここ何日かで英語の重要性が分かった
頑張って勉強したんでみんなを追い越したよー
すごいだろー
64:デフォルトの名無しさん
08/01/07 17:06:13
>>63
先逝ったか？ 南無阿弥陀仏。
65:デフォルトの名無しさん
08/01/08 11:41:54
英語なんかやっても会話ができるわけでもないしイラネー
66:デフォルトの名無しさん
08/01/08 17:23:26
コピペ、コピペっと。
>>65
当然英語はできるんですよね？
67:デフォルトの名無しさん
08/01/08 19:51:53
英語出来たら人生の難易度がガクッと落ちちゃいそうだから勉強しない。
68:デフォルトの名無しさん
08/01/08 23:58:59
やるなら韓国語でいいよｗ
69:デフォルトの名無しさん
08/01/09 00:15:42
URLﾘﾝｸ(www.nicovideo.jp)
この動画見ていたらdolphinとか笑えなくなってしまいました（笑）
70:デフォルトの名無しさん
08/01/09 15:19:47
英語出来なくても読めれば十分だしｗ英語が必要なときなんかはせいぜいその程度ｗ
71:デフォルトの名無しさん
08/01/09 20:03:45
おまいら違う言語の話題に熱心でつね。
72:デフォルトの名無しさん
08/01/12 23:32:34
パラメタに名前を付けてゴニョゴニョしたい場合ってアノテーション使うしかない？
public hoge(@Named("foo") int foo,@Named("bar") int bar)みたいに。
73:72
08/01/12 23:33:33
>>72
あっ、すいません。質問スレと間違えました。
74:デフォルトの名無しさん
08/01/14 15:53:35
Java SE 6 Update 4 リリースノート
URLﾘﾝｸ(java.sun.com)
OGL: フラグメントシェイダーを使用して Linear/RadialGradientPaint を高速化
OGL: フラグメントシェイダーを使用して Convolve/Rescale/LookupOp を高速化
最近は色々な描画エンジンがシェイダー言語を使うようになってきたなぁ。
75:デフォルトの名無しさん
08/01/14 15:58:48
シャイダー言語ってどういう宇宙刑事語？
76:デフォルトの名無しさん
08/01/14 16:14:47
× シャイダー
○ シェーダ
URLﾘﾝｸ(ja.wikipedia.org)
77:デフォルトの名無しさん
08/01/18 02:29:45
>>75
メタルダーだ
78:デフォルトの名無しさん
08/01/18 12:54:35
じゃあ一番は誰なんだ？
79:デフォルトの名無しさん
08/01/18 19:29:35
ナンバーワンダ
80:デフォルトの名無しさん
08/01/22 08:16:44
URLﾘﾝｸ(www.infoq.com)
Rubyですらこれができるようになるのに・・・
81:デフォルトの名無しさん
08/01/22 08:51:43
プロセス単位で起動すりゃ良いし、もしアレならクラスローダー単位をインスタンスと
見りゃ良いし、それってそもそも必要なの? メリットがよう分からん。
82:デフォルトの名無しさん
08/01/22 09:01:24
コレは便利 ＦｉｒｅｆｏｘをＩＥ化するマニュアル
Firefox 2.0.0.11 Windows版(5.7MB)ダウンロード
URLﾘﾝｸ(www.mozilla-japan.org)
IE Tab 1.3.3.20070528 FirefoxをIEエンジンに
URLﾘﾝｸ(addons.mozilla.org)
Firefox ＞ ツール ＞ IE Tab のオプション
サイトフィルタ ＞ URL: [http:// ]を入力 [適用] [ＯＫ]
83:デフォルトの名無しさん
08/01/22 11:05:54
>>81
それができるのはRubyだからというのはあると思うぞ。
JavaもAPI制限を加えれば、できるかもしれんが
スレッドのアプリごとの分離やそのリソース配分をどうするかっていう問題とか色々ある。
Zoneで使ったような解決方法でいいと思うんだけどね。
で、起動のオプションでMVMで動かすかシングルで動かすかを
指定できればいいのかな。
メリットは、ユーザが頭を悩まさずに使えるか、という部分だろ。
クラスローダ単位とかは、ちょっとテクニカルすぎる。
84:デフォルトの名無しさん
08/01/22 11:46:12
いや、だからそれを使うとなんか革命的な設計でも出来るわけ? 同一プロセス内で
複数のアプリケーションが独立して動くのはアプリケーションサーバで普通にやってるしょ。
テクニカルも糞も、パーティション(?)ごとに URLClassLoader 作ってそれぞれ main
となるスレッドに適当なクラスの main() か何かを呼び出すだけでしょ。
必要ならパーティション内でスレッドプールでも作ればいい。ライブラリならJakartaにも転がってるし。
まぁブートストラップクラスまで完全分離するのはちょっと無理だし、プロセス内で
仮想化ソフト並みのリソース管理システムでも構築できるってなら話は別だが。
意図が良く分からんので Java よく分かってない人が Ruby ﾏﾝｾｰ しに来て失敗してる
ようにしか見えんのだが。
85:デフォルトの名無しさん
08/01/22 12:01:46
たぶん、あれば便利だよねっとことだろ。
リソース管理とか実現した後の話しだし、ならおまえは仮想化ソフト使えよ
86:デフォルトの名無しさん
08/01/22 12:01:50
MVMという話は、Java発祥だと思ってたんだが・・・・
87:デフォルトの名無しさん
08/01/22 12:05:26
なんだ、下らん。
88:デフォルトの名無しさん
08/01/22 12:54:42
ちょっと調べたが、今の Ruby は一つのプロセスにつき一つしか VM のインスタンスを
持てない。これは別プログラムから拡張ライブラリとして Ruby を呼び出しても同じ。
だから Apache の CGI として実行すると一つの VM で全てのリクエストを
こなす構成になり、素人が扱うには挙動がやっかいじゃのう、という話か。
JDK 1.2 以上の JNI 使っての Java 機能呼び出しは同一プロセスで複数 VM 起動もイケます。
--- 愁傷 ---
89:デフォルトの名無しさん
08/01/22 12:57:31
isolationって奴だよな。
URLﾘﾝｸ(en.wikipedia.org)
URLﾘﾝｸ(jp.sun.com)
90:デフォルトの名無しさん
08/01/22 13:02:16
JavaのMVMが研究レベルから進まなかったのは、不正なメモリアクセスを行う
バグ持ちのネイティブコード呼び出しへの上手い対応が考えられなかった
からだと聞いたことがある。
Rubyもネイティブコードの呼び出しが出来る以上同じ問題にぶつかると思うけどね。
あるアプリがバグ持ちのネイティブコードを呼び出したとき、
JavaVM/RubyVMの管理するヒープを破壊されたとすると、
VMにホストされている全てのアプリが暴走するといった類の問題に
対する解答を用意することができるのかという所。
ちなみにネイティブコードの呼び出しが行えない携帯向けJavaVMでは、
実用化され既にMVMは普及しているレベル。
JSR 121,Application Isolation API Specificationだとかはどうなるんだろうねぇ。
91:デフォルトの名無しさん
08/01/22 13:10:21
それのゴールは Java VM の常駐なのかね? そういうことなら良さそうだな。
92:デフォルトの名無しさん
08/01/22 13:16:00
>>90
頑張って研究してくれよ
93:デフォルトの名無しさん
08/01/22 13:16:36
>>90
プロセス(タスク)に分離して、OSの保護機構を利用して、
それぞれのVMはプロセス(タスク)間通信で情報をやり取り。
94:デフォルトの名無しさん
08/01/22 13:29:16
>>93
素人が口だしするなｗ
95:デフォルトの名無しさん
08/01/22 13:58:41
>>80の元記事にそう書いてあんじゃね?
パイプうんぬんのところは未実装なんだろうけど。
96:デフォルトの名無しさん
08/01/22 21:46:41
妙なネイティブライブラリがクラッシュして全部巻き込まれるのはアプリケーションサーバでも同じだな。
それ対策のためにわざわざ RMI→JNI 経由して COBOL 呼ぶ設計をしたことがある。
IBM なんかそういうフォールトトレラントの研究はしてそうだが WebSphere にも実装されてないな。
97:デフォルトの名無しさん
08/01/23 02:58:02
>>96
やっぱりそうしたら良かったかなと、自作のプログラム相手に悩んでる。
いまんとこ20日くらいは持つんだが。
使っているのはあるライブラリのJava APIで、そいつがさらにJNIを...というパターン。
98:72
08/02/07 18:52:18
raw文字列のサポートの計画はないですか？
pythonみたいにr"\d"とか書ければうれしいです。
99:デフォルトの名無しさん
08/02/07 19:04:42
それの型って byte[] ?
100:デフォルトの名無しさん
08/02/07 19:36:19
Regular Expressionのrだと思ってた。
XMLリテラルも欲しいな。
101:デフォルトの名無しさん
08/02/07 20:25:40
"hoge".getBytes() は？
102:デフォルトの名無しさん
08/02/09 00:50:44
そういう問題じゃなくて
103:デフォルトの名無しさん
08/02/09 01:03:18
>>98
いまのところ聞かない。クロージャでもめてるし、JDK7じゃ望み薄かも？
104:デフォルトの名無しさん
08/02/09 19:18:14
>>98
それはサポートされたら地味に嬉しいな。
テンプレート的な文字列とか、正規表現書くとき悩まなくてすむ・・・・
105:デフォルトの名無しさん
08/02/09 21:01:22
あとソースコードにエンコード指定のメタデータ書けるようにしてほしい・・・
106:デフォルトの名無しさん
08/02/10 01:28:32
URLﾘﾝｸ(slm888.com)
CICE ARM のプロトタイプだそうで。
クロージャ案の中で CICEが一番タイプ量多いんだよなぁ。
ぶっちゃけCICEだけだったら匿名クラスがあるから要らんような。
ARMは欲しいけど。
107:デフォルトの名無しさん
08/02/10 16:36:05
>>105
それは欲しい。ソースコードが単体で完結せず、エンコーディングというメタデータが必要なのは痛い。
108:デフォルトの名無しさん
08/02/10 16:40:52
UTF-8 で統一しとけよ…
109:デフォルトの名無しさん
08/02/10 17:24:40
>>106
List<String> list を大文字小文字区別せずに整列させる場合だと、こんな感じか。
無名クラス：
Collections.sort(list, new Comparator<String>(){ public int compare(String s1, String s2){ return s1.compareToIgnoreCase(s2); } });
CICE：
Collections.sort(list, Comparator<String>(String s1, String s2){ return s1.compareToIgnoreCase(s2); });
FCM：
Collections.sort(list, #(String s1, String s2){ return s1.compareToIgnoreCase(s2); });
BGGA：
Collections.sort(list, {String s1, Strings2 => s1.compreToIgnoreCase(s2) });
110:デフォルトの名無しさん
08/02/10 17:46:12
>>108
javacもIDEも、デフォルトのエンコーディングが環境依存だし
ソースファイル単位で指定できればかなりありがたいんだけど…
packageの次あたりに
encoding "UTF-8"
みたいに書いて指定出来るといいのになあ。
111:デフォルトの名無しさん
08/02/10 17:49:36
>>109
どれも汚ｯﾀﾈｰのな。
112:デフォルトの名無しさん
08/02/10 18:02:48
>>109
面白いけど、どれもパッとしない
Javaらしい気持ち悪さ
113:デフォルトの名無しさん
08/02/10 18:05:58
Logging API の時みたいに間に泡ねーとかそういう理由で適当にでっち上げてもらいたくないね。
ライブラリレベルの話じゃないんだし。
114:デフォルトの名無しさん
08/02/10 18:11:35
>>113
クロージャの事を言ってるなら、
もめてるのは議論してどうこうできるレベルの話じゃないような。
「Javaらしさ」なんて、そんなもん個人個人で違うんだから議論にならんし。
時間かければどうにかなるもんじゃないと思うが。
115:デフォルトの名無しさん
08/02/10 18:12:31
そもそも時間かけたはずのgenericsがあの体たらくだしな
116:デフォルトの名無しさん
08/02/10 18:17:37
もうHaskell風に(\s1,s2 -> s1.compreToIgnoreCase(s2))でいいよ
Stringくらい型推論しろ
117:デフォルトの名無しさん
08/02/10 18:32:46
そうか、そうだな。時間かけて話し合えば良い物できるできるというものでもなかったな。
声のでかい順に嗜好を取り込んだ最小公倍数的仕様が最良になるとは思わないし。
逆にセンスのある一人の天才が作った方がシンプルで良い。
118:デフォルトの名無しさん
08/02/10 18:39:00
>>116
C#でも仮引数型の型推論してくれたような。
119:デフォルトの名無しさん
08/02/10 18:43:23
仮引数型の型推論は、後付けで導入できるんだったら後回しでもいいような気もする。
他の部分で型推論を導入する際の一貫性みたいなもんもあるし。
120:デフォルトの名無しさん
08/02/10 21:54:02
Javaもサーバだけじゃなく一般的になってきて、変なのまでJavaを使うようになってしまったんだな。
変な奴やC#かC++に行ってくれ。
121:デフォルトの名無しさん
08/02/10 22:09:26
>>120
さようなら、変な人。。
122:デフォルトの名無しさん
08/02/10 22:26:23
順調にJavaも巨大になってきてるね。
まあいじくられる対象ってのはそういうもんだよね。
123:デフォルトの名無しさん
08/02/10 22:32:44
ただ大勢で規格を開発された言語ってのは、
あまりいい感じにならないんだな。
PL/1, Ada, Common Lispなど。
規格管理だけならいいんだけど。
124:デフォルトの名無しさん
08/02/10 23:28:46
そりゃこういう連中は総じて自分の業績と功名心の下心でやってるんだから仕方がない。
スタンダードさえ勝ち取れば、中身が多少糞なのは 「解釈の問題」 とでも言っておけば
後世まで評価されると言うことを彼らはよく知っている。
125:デフォルトの名無しさん
08/02/15 09:54:54
>>123
重要ところが抜けているけど、javaは規格じゃなくてあくまで企業やjavaを活用する団体が管理している。
ISOとか関係ないから、それでは例えが悪くそもそもそれらの言語とは比べられない。
おまえは言語使用とライブラリは分離されているとか、そんなところも見えてないだろｗ
126:デフォルトの名無しさん
08/02/15 10:29:22
（ ﾟдﾟ）ﾎﾟｶｰﾝ
127:デフォルトの名無しさん
08/02/15 20:15:06
>>126
大事なところ指摘してるのが分からないんだね。低脳さんｗ
128:デフォルトの名無しさん
08/02/15 20:26:54
悪いが俺も >>125 は勝手に話を広げてるようにしか見えないわけだが。
129:デフォルトの名無しさん
08/02/15 20:40:23
規格(standard)ではなく仕様(specification)と言えというのならまだわかる。
130:デフォルトの名無しさん
08/02/15 21:29:54
話は変わるがJavaはSEやEEにどの機能を入れるかというJSRがあるのがいいな。
EE6の場合だとこれだけの機能を追加するのにいくらかかるという資産までしてるみたいだし。
131:デフォルトの名無しさん
08/02/15 21:35:36
資産(asset)ではなく試算(trial calculation)と言えというのならまだわかる。
132:デフォルトの名無しさん
08/02/15 23:31:20
揚げ足鳥ってこういうことになっていつも非生産的な行為でしかない。非生産的なジャヴァ言語と同じ。
133:デフォルトの名無しさん
08/02/15 23:31:55
なんというこじ付け
134:デフォルトの名無しさん
08/02/15 23:41:16
>>129
>>123-127のレスには「仕様」のことは触れてないようだが、
どこからそんな指摘が出来るんだ？
ところで英語で言えばカッコいいなどと思ってるなら考え直した方がいいだろう。
135:デフォルトの名無しさん
08/02/15 23:42:51
もちろん英語はできるんですよね？
136:デフォルトの名無しさん
08/02/15 23:44:42
>>125みたいな変人はどこにでもいるから。
137:デフォルトの名無しさん
08/02/15 23:52:25
とっても口惜しそうだねｗ
138:デフォルトの名無しさん
08/02/15 23:53:55
若干一名な。
139:デフォルトの名無しさん
08/02/15 23:54:09
（´･∀･`）ﾀﾞﾖﾈｰ
140:デフォルトの名無しさん
08/02/15 23:56:46
くだらないことをいつまでも続けるのがねらーの悪いとこだな
アダルトチルドレンが多すぎ（古館的な意味で）
141:デフォルトの名無しさん
08/02/15 23:58:12
↑アダルトチルドレン（古館的意味）とは、正しくおまえのことだな
142:デフォルトの名無しさん
08/02/15 23:59:39
クロージャーの議論で、ゴズリンは愚痴ってるけどでもやる気みたいだけど、結局クロージャはどうなるの？
143:デフォルトの名無しさん
08/02/16 00:02:17
>>141
こういうループ野郎がねらーそのもの
144:デフォルトの名無しさん
08/02/16 00:03:49
（´･∀･`）ﾀﾞﾖﾈｰ
145:デフォルトの名無しさん
08/02/16 00:10:54
若干一名って、おまえの思い込みなだけじゃないのかｗ
146:デフォルトの名無しさん
08/02/16 00:17:17
（´･∀･`）ﾀﾞﾖﾈｰ
147:デフォルトの名無しさん
08/02/16 00:18:37
とっても口くやしそうなのが若干一名います。
148:デフォルトの名無しさん
08/02/16 00:23:00
（´･∀･`）
149:デフォルトの名無しさん
08/02/16 00:24:20
（´･A･`）ﾀﾞﾖﾈｰ
150:デフォルトの名無しさん
08/02/16 00:27:54
>>125の人気に嫉妬。
>>142
ゴスちゃん一人がそんな影響力あるわけじゃないから。
言語開発者であった初期だけでなく、
Javaの方向性に大きな影響を与えたけど、
もうそろそろいいでしょ。
151:デフォルトの名無しさん
08/02/16 00:30:28
>>142
派閥が出来てる状態で言語仕様に深く関わる機能を盛り込めはしないでしょう。
てかサーフィンしてたらSE7にEJB3が追加されるってブログを見つけた。
Webサービスじゃなくて何故にEJB？
152:デフォルトの名無しさん
08/02/16 00:54:37
というか、いまどき「サーフィンｗ」ってなに？
153:デフォルトの名無しさん
08/02/16 00:56:18
また沸いてら
154:デフォルトの名無しさん
08/02/16 01:10:52
>>151
クロージャに限定すれば、BGGAとかの派閥といってもクロージャの書き方というかリテラルが少し違う程度だろ。
Genericsのようにどこまでテンプレート・プログラムを認めるかと同様に、
クロージャをどこまで広げるかの考え方はあるだろう。
しかし、それを議論していても結局は内部クラス（匿名クラス）でいいのかの議論に戻ってしまうし
とすれば、派閥とかいってもリテラルが簡単か否かの違いでしかない。
それとゴズリン（のUNIXでの貢献も含めて）のそのセンス自体がそのままJavaの思想やセンスになっていると思うんだが？
C#はたいした手間でもないのに何でもリテラルして言語仕様にしたりするけど、正直キモイ。
やっぱりMSはいつまでもハンガリアンだしｗ
155:デフォルトの名無しさん
08/02/16 01:15:32
派閥まで出来とるのか。
ブラウザで踊ってるデューク見て感動していた頃の古き良き時代が懐かしい。
156:デフォルトの名無しさん
08/02/16 01:20:22
Javapolis(source)の調査結果は賛否両論であった。
30人の参加者はCICEに賛成し、
BGGA/FCM+JCAは２４人の賛成を得た。
そして、19人が変更しないことを選 んだ。
URLﾘﾝｸ(www.infoq.com)
157:デフォルトの名無しさん
08/02/16 02:25:40
そのは記事以前も見た気がするけど、記事の本人（外人）自体が「Javaらしさ」を
追求しすぎてバイアスがかかってるってことに気がついてない。
クロージャの話なのにScalaとか勧めてるし、多分バカなんだろ。
クロージャってのは中途半端な内部クラスの設計を、さらに拡張して完成させる程度でしかないだろうな。
C++のtemplateかと思ってたらgenericsは思ってたのと全然違ってたし、
クロージャもアレコレ議論するのはオープンでイイが、同じくそんな感じに落ち着くんじゃないか？
うまくいけばゴズリンが大好きなemacs lispにまでもっていければってところ。
158:デフォルトの名無しさん
08/02/16 02:28:00
もういっそヒアテキストで他言語埋め込めるようにすりゃ全て解決するだろ。
159:デフォルトの名無しさん
08/02/16 02:52:13
char c= "abc".charAt(1);
int z= {int x, int y => x+y}.invoke(2,3);
で、BGGAはStringリテラルと似たようなもの。
CICEは匿名クラスが少し短縮してある程度でしかない。
new Thread(new Runnable() {
public void run() {foo();}
}).start();
new Thread(Runnable(){ foo(); }).start();
160:デフォルトの名無しさん
08/02/16 02:53:10
>>158
全くイメージできないんだけど、どういうこと？
161:デフォルトの名無しさん
08/02/16 02:58:08
どちらにせよライブラリレベルじゃ不都合だったり出来なかったことが
可能になるわけじゃないから、匿名内部クラスを普通に使ってる人間には
言語汚染にしか見えんのー。
162:デフォルトの名無しさん
08/02/16 03:04:54
>>157
Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahe の４人が
進めている下記のクロージャ仕様(BGGA)ならまともなものだと思うぞ。
URLﾘﾝｸ(www.javac.info)
これがjava7の仕様の一部となることを願うんだ！
163:デフォルトの名無しさん
08/02/16 03:07:36
int x = (Integer)new Function("JavaScript", "alert('hello, world');return 100;").exec();
とかで十分だと思うんだ俺…
164:デフォルトの名無しさん
08/02/16 05:18:51
別にｲﾗﾈｰ気もするんだが、自分がいる間に目玉商品機能を作りたいもんなんかね、中の人的には。
165:デフォルトの名無しさん
08/02/16 08:45:46
要るわ。>>162がいい。
166:デフォルトの名無しさん
08/02/16 12:26:06
そろそろLegacyJavaとか言って1.4をメンテし始めて欲しいのだが
167:デフォルトの名無しさん
08/02/16 12:29:51
>>163
それは、普通に使われるとセキュリティーに穴が開くからヤバイと思う。
168:デフォルトの名無しさん
08/02/16 12:48:06
Java 6 からは Scripting API というものがあってだな（ｒｙ
169:デフォルトの名無しさん
08/02/16 13:33:31
finalと匿名クラスのシンタックスシュガーを用意するだけだよね？
foreachみたいに特定のインタフェースを持ったオブジェクトに適用されるような。
そうなるとJVMがインタフェースを登録するタイミングが気になる。
JEEでClassNotFoundExceptionをやらかす人を増やす仕様だったらどうしよう。
何百個というインタフェースをjava.lang.closureに放り込んで
ブーストラップクラスローダーでロードさせとくとかそういう仕様？
170:デフォルトの名無しさん
08/02/16 14:47:57
クロージャをイベント処理とかでよく使う匿名クラスの延長と見るか、
全く新しいパラダイムと見るかじゃないか？
全く新しいといいつつも、
{void => void} .equals( new java.lang.Function() {
public void invoke(){}
}
と同じことを仕様として入れたいのだろうけど。（多分）
内部クラスあるけど、GUIだといつも使うし<... onclick="callback()"> のように書ければいいよねだろ。
大元の発想は。
"abc".equals(new String("abc"))
と同程度なことが実現できるメソッド・バージョン。
クロージャを何に活用するかは議論してるみたいだし、知らん。
171:デフォルトの名無しさん
08/02/16 15:08:49
>>168
Java 6が出た当初はjsとの連携なんていらんだろと思ってたけど、最近はjsがお気に入り☆
java.nio とか当初はjava.ioあるし、いらんと思ってたけど、これもなかなか。
内部クラスあるし今はクロージャなんて全くいらんとかかも知れんが、クロージャも同じく「なかなか」になるのかと思う。
172:デフォルトの名無しさん
08/02/16 15:42:56
リリース予定は今年でおｋ？
173:デフォルトの名無しさん
08/02/16 15:46:38
JSRが提出されるのはSE7のが先じゃないの？
BGGAもv0.5とかなってるし、間に合わない気が
174:デフォルトの名無しさん
08/02/16 22:42:22
まったくクロージャを策定するのは苦労じゃ。
175:デフォルトの名無しさん
08/02/16 22:46:25
そうだね
176:デフォルトの名無しさん
08/02/16 23:07:33
＿＿＿＿ CICE版
|← reject| BGGAの中の人 Closure ユーザー
.￣.||￣￣ ┗(^o^ )┳(｀Д´)┳(^o^ )┛≡＝-
|| ┏┗ ┗┗ ┏┗ ≡＝-
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
177:デフォルトの名無しさん
08/02/23 00:23:23
>>156
URLﾘﾝｸ(www.java.net)
こっちの投票だと CICE 3.9%、BGGA 42.7%で 10倍も差がついてる。
javapolisだと、josh blochの公演があったからそれに引きずられたんだろね。
公演前は 2:1 でBGGAの方が投票多かったって書いてあるし。
派閥っても、公演一回でひっくり返るレベルなのよね。
178:デフォルトの名無しさん
08/02/23 03:01:15
まあ、長く使わんと手に馴染み具合が分からんですよねぇ
正直、CICEは今の匿名クラスに比べて何がメリットかよく分からないので却下したい。
BGGAは、表記がごちゃごちゃして新しい構造が入ってくるので
ぱっと見た目、1.4世代の人が見たらもう分け分からんことになりそうだな、という不安。
まあ、そう言う人は十分Genericsでも分からないコードになってるのかも知れないけど・・・
この表記ならついでに複数返り値もサポートして欲しい感じ。
FCMは、Cとかの関数ポインタに似てるのですっきりしてていいかもしれない。
今のところ一番分かりやすいけどthis#hogehoge()とかしたときに
実行コンテキストが見た目的に予測しにくいな。
ただ、>>106 のARMは欲しい。
こういう分かりやすくなる変更は歓迎したい。
Genericsは訳分からなくなったし。Closureには同じ轍を踏んで欲しくない・・・・
179:デフォルトの名無しさん
08/02/23 09:10:53
ARMよりは、BGGAのcontrol invocation syntax使える方が嬉しいけど。
ARMってjava.io.Closeableとか、java.util.concurrent.locks.Lockとか
特定のinterface実装してないと使えないみたいだし。
FCMにもJCAあるけど、これはライブラリ側の書き換えが必要になるんかな
180:デフォルトの名無しさん
08/02/23 23:01:24
匿名クラスを少しいじってみたけど、結局GUI辺りとか、イベントでしか使わないよ。
だからゴチャゴチャして分からなくなるとかはお門違いだと思った。
BGGAとかFCMとか表記やタイプ量が違うだけど、内部では匿名クラスと全く変わんないし。
確かにクロージャは、イベントを超えてラムダみたいに何か活用するなら今までと全く違うから抵抗あるのかもしれない。
必要ないと考えてる奴らはイベント程度でしか見てないし、
イベント以外の活用が見出せないだけじゃないか？
匿名クラスを少し使ってみたら、新しいクラス生成式
（クラス生成リテラル）ってところだなと感じた。
181:デフォルトの名無しさん
08/02/23 23:02:49
匿名クラスと比べてみたら、新しい
182:デフォルトの名無しさん
08/02/23 23:07:22
内部匿名クラスは、やっぱりjdk1.0のイベント処理方法の不満から解決策として出てきたんだし、
匿名クラスの設計（や表記方法）が中途半端というのはよく分かる。
本心としては、昔は急いでたから匿名・関数生成リテラルまで設計してなかったこと
についての後始末ってとこなんじゃないか？
183:デフォルトの名無しさん
08/02/23 23:20:19
でもたいして変わらないものにしかならなさそうなんだけど。
184:デフォルトの名無しさん
08/02/23 23:33:17
そもそもクロージャ自体「使わなくてもいい便利なもの」扱いしてる時点で「匿名クラスと大して変わらないもの」あつかいされるのは仕方ないんじゃないか。
匿名クラスのシンタックスシュガーレベルの扱いじゃなくて、通常のメソッドがクロージャの簡易構文になってるぐらいでないと意味ない気がする。
185:デフォルトの名無しさん
08/02/24 00:18:33
>>182
匿名クラスの設計も表記方法も完成されてると思うよ。
単にタイプ数が多くなるから面倒くさいだけで。
匿名クラスを弄ったCICEが進化だとか、
CICEで匿名クラスは完成された、とか言うなら話は別だけど。
186:デフォルトの名無しさん
08/02/24 07:18:15
匿名クラスは匿名クラスでいいが、
クラスである必要のないところにはクロージャを使いたい。
クラス至上主義は要らない。関数は関数だ。
187:デフォルトの名無しさん
08/02/24 07:21:55
匿名内部クラスより (数値の上でだけでも) パフォーマンスが良いとかあればまだ良いんだけどね。
188:デフォルトの名無しさん
08/02/24 10:28:49
それが無いと困る場合というのが明確でない機能は
追加せんでもいいと思うんだが。
ジェネリクスやプロパティまでは理解できたが、
クロージャは必要性がよくわからんな。
189:デフォルトの名無しさん
08/02/24 14:09:45
JDK1.6のコンカレント関連のFeature<T>とか見たときに、いい加減第一級の関数型なしに匿名クラスでエミュレーションするのは苦しいだろうと思ったのだが、おまえらはどうだ？
190:デフォルトの名無しさん
08/02/24 14:27:15
もう JCP は勝手に別の言語でも作っててもらいたいんだが。
191:デフォルトの名無しさん
08/02/24 14:33:28
>>189
禿同。
何でもクラスと言われたSmalltalkより酷いことになってる。
まさにクラス馬鹿一代。> Java
192:デフォルトの名無しさん
08/02/24 14:44:48
>>189
苦しいというほど頻繁に使われるシーンが思い浮かばない。
Threadとかもあるし、俺はこの程度なら言語仕様を汚してまで
導入する意義は薄いと思うな。
193:デフォルトの名無しさん
08/02/24 14:49:35
汚れない
194:デフォルトの名無しさん
08/02/24 15:54:36
>>189
Future<V>はクラスで適切だと思うけど。
Callable<V>インターフェイスを実装した匿名クラスを書くのが面倒なので
クロージャ使わせろという話と勘違いしていない？
あと、BGGAの block.invoke(args) って記法を block(args) って書けるように
してほしいなぁ。
まあ、RubyのクロージャもWikiPediaによると
># 後に必要になった時点でクロージャを呼び出す。
>@block.call("John")
># 表示:"Hello, John!"
と書いてあって、RubyもJavaのBGGAと同じくあくまでクロージャを
オブジェクト扱いしているっぽい。
なので、Rubyのblock.call(args) みたいに、クロージャの呼び出しは
オブジェクトのメソッド呼び出しと同じように書くのが普通なのかもしれんけど。
195:デフォルトの名無しさん
08/02/24 16:06:07
> あと、BGGAの block.invoke(args) って記法を block(args) って書けるように
おれもして欲しい。
けどクロージャができるまでは、メソッドの名前空間と
フィールド/変数の名前空間で分かれてたのに、
closure(arg)を許すと、区別つかなくなるから難しいんじゃね？
196:デフォルトの名無しさん
08/02/24 16:13:21
>>192
ぶっちゃけ、プロパティ導入の方が言語仕様が汚れる。
>>195の反対の理屈で、いままでメソッドだったものが
フィールド/変数の名前空間使うことになるから。
197:デフォルトの名無しさん
08/02/24 16:27:53
プロパティはほんと汚れるって感じするわ。便利だけどw
198:デフォルトの名無しさん
08/02/24 16:33:31
プロパティがないとRADサポートできない。
199:デフォルトの名無しさん
08/02/24 16:47:13
「どっちがより汚いか」なんて議論しても意味ねーw
新しい表記、文法の導入はどっちにしても「汚れる」ことに変わりない。
重要なのはそれを許容するだけのメリットがあるかどうか。
200:デフォルトの名無しさん
08/02/24 16:50:42
クロージャでもBGGAの場合は、RAIIっぽい事ができるってメリットあるけど、
プロパティは基本的にタイプ数が減るだけ。
201:デフォルトの名無しさん
08/02/24 16:52:58
>>199
汚れる程度の問題もあるんだよ。
プロパティ導入は下手するとソース互換性破壊するし。
202:デフォルトの名無しさん
08/02/24 16:53:53
コンポーネント志向にはプロパティが必要。
203:デフォルトの名無しさん
08/02/24 16:55:26
beansのプロパティで我慢
204:デフォルトの名無しさん
08/02/24 17:07:46
>>201
バイナリ互換性じゃなくてソース互換性？
「下手すると」って書いてるけど、どの案でどういう問題が？
205:デフォルトの名無しさん
08/02/24 18:03:08
>>204
あるクラスにプロパティ hoge と、フィールド hoge があった時に、
識別子 hoge で、フィールドとプロパティどっちアクセスすんの？って話。
プロパティ hoge の宣言と、フィールド hoge の宣言を排他にすりゃ問題ないけど
beans のプロパティ hoge と、フィールド hoge は共存できてたわけで、
安易に排他にするとソース互換性を破壊する。
アクセスレベルのルールをちゃんと考えれば互換性たもてるかもしれんが、
失敗すればフィールドアクセスのつもりがプロパティアクセスになったりしてソース互換性破壊する。
頑張ってアクセス時のルールで互換性維持したとしても
プロパティ hoge を継承クラスのフィールド hoge で隠蔽できるようになったりする。
206:デフォルトの名無しさん
08/02/24 18:26:02
排他にすりゃいいし、フィールドで隠蔽できないようにすりゃいい。
というか、draft3はそういう案じゃなかったか？
で、それが「安易に排他にする」ことだとして、そこで発生する問題は何？
207:デフォルトの名無しさん
08/02/24 18:30:18
>>206
標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。
beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。
っつーか、draft3 ってどれの事いってるん？
208:デフォルトの名無しさん
08/02/24 19:00:33
これね。
URLﾘﾝｸ(docs.google.com)
>標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。
そこであらかじめ定義されたプロパティと同名のフィールドをサブクラスで
定義しなきゃならないケースというのが想像できないんだけど？
もしそれが問題になるんなら、親クラスで定義されるのがプロパティじゃなくて
フィールドでも一緒じゃね？
>beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。
beansと関係ないからこそソース互換性を保てるわけなんだが。
209:デフォルトの名無しさん
08/02/24 19:48:02
>>208
自前のクラスで、標準APIのクラス Hoge を継承する SubHoge に、
フィールド hoge が宣言されてるとする。
これは既存のソースでプロパティ導入前にはなんの問題もないけど、
プロパティが導入されて、標準APIのクラス Hoge にプロパティ hoge が後付で導入され、
おまけにプロパティとフィールドが排他だとなると、ソース互換性が破壊されるわけ。
フィールドは隠蔽されるだけだし、最初から存在するルールだからソース互換性は破壊されない。
210:デフォルトの名無しさん
08/02/24 19:59:01
標準API ：
class Hoge{ abstract Hoge getHoge(); }
ユーザ側：
class SubHoge extends Hoge{
Hoge hoge;
Hoge getHoge(){ return hoge; }
}
で上手くいってたのに、
プロパティ導入して、標準APIが
class Hoge {
abstract Hoge getHoge();
abstract property Hoge hoge;
}
とかに変わると、SubHoge はコンパイル通らなくなるわな。
211:デフォルトの名無しさん
08/02/24 20:04:42
後付けでプロパティ追加なんてしなきゃいいじゃん。
これができないとどういう場合に困るの？
212:デフォルトの名無しさん
08/02/24 20:12:09
>>208
あと、beansとの互換性を維持する場合の問題は別にあって、
同名のプロパティが言語仕様上は共存できるとかね。
例えば
interface Hoge {
boolean isHoge(); void setHoge(boolean b);
Hoge getHoge(); void setHoge(Hoge hoge);
}
は、言語仕様上は問題ない。
だけどプロパティとしては同名プロパティが複数あるので曖昧になる。
beans仕様は厳密じゃないから、どっちを優先的にプロパティにするかとか、
実は同名プロパティを複数持ったbeansは不正なのか、みたいな事を記述してない。
java.beans.Introspector が決める事になってるみたいだけど、
これもブラックボックスで振る舞いは文書化されてない。
で、beansと互換性のあるプロパティを言語仕様に導入しようとしたとき
Hoge hoge;
System.out.println(hoge.hoge);
とかなったとき、getHoge() を呼ぶべきか isHoge() を呼ぶべきか？
はたまた同名プロパティは宣言できないようにすべきか？ みたいな問題が出てくる。
まぁ、こーゆーのが現実に問題になるケースは少ないと思うけど
言語仕様上はきっちり決めとかないといけないから。
213:デフォルトの名無しさん
08/02/24 20:33:45
みんなきちんとIntrospectorを使っているんならまだましだけど、
勝手にやっちゃってるフレームワークが氾濫しているのも問題だよな。
214:デフォルトの名無しさん
08/02/24 20:41:35
今時プロパティのない言語は時代遅れ。
215:デフォルトの名無しさん
08/02/24 20:44:49
get/setをエディタが補う時代にプロパティとかいらんだろ
でもプロパティってバインド機能があるんだっけか
216:デフォルトの名無しさん
08/02/24 20:48:48
追加はしてくれるけど、消したり隠したりしてくれないんだよな。
217:デフォルトの名無しさん
08/02/24 21:27:05
正直クロージャすらない言語は時代遅れ
218:デフォルトの名無しさん
08/02/24 22:29:55
func.invoke(20)をfunc(20)にするのだけど、確かに見た目と意味が一致していい気がするけど、
int y=new {int a=>a+1}.invoke(20); は分かるが、
int y=new {int a=>a+1}(20); これはどうかと思わないか？
プロパティとかクロージャも含めて、言語仕様にリテラルを入れるのは
直接的には省略した記法でしかない。
やっぱり、それを新規に導入するだけのメリットがあるかどうかだろ。
ジェネリクス同様、所詮はCのマクロの置き換えと同じだしｗ
219:デフォルトの名無しさん
08/02/24 22:34:53
そんな使い方しないってw
あほかよ
220:デフォルトの名無しさん
08/02/24 22:44:47
int x = (Integer)new Function("text/javascript", "1+1").invole();
やっぱりこれで良いんですけど。
221:デフォルトの名無しさん
08/02/24 22:45:52
タプルと演算子オーバーロードは、確か、絶対にサポートしないってどこか書いてあった（英語）。
bigdecimalのオペレータ[+,*とか]・オーバーロード・サポートもあんまり期待できない。
byte b; Float o;
{b, o}=init(something);
クラスを定義するほどでもなく、ちょっと利用のつもりでこんな感じだろうけど、
Object[] init(something){return new Object[]{new Byte(2), new Float(2.1)};}
この長い書き方で実質的に展開されるんだろうし、別にリテラルとしてサポートするメリットな意味ない。
クロージャ（GUIイベントを主とした）と違って、あんまり必要としてる人はいないみたい。
配列じゃなくてクラスを返し他方が、他の人が読んでも分かるみたいで、private
で使うんじゃないか？オレなら、publicやprotectedのメソッドでは、こういうAPIがあると作った人を疑っちゃうけどね。
222:デフォルトの名無しさん
08/02/24 22:49:53
演算子オーバーロードのサポートも時間の問題と思われ
223:デフォルトの名無しさん
08/02/24 22:53:26
それと、クラスをメモリ上に一旦読み込んでしまえば、
匿名クラスとかクロージャとかで関数一つでもクラスをいちいち生成される
とか気にしても、性能に全く関係ないよ。
.classでもメモリ上ではCのように速さとか性能はほぼネイティブと同じになるし、
せいぜいメソッドで動的呼び出しか、静的呼び出しかの違いぐらいじゃないか？
それに、C、jvmくらべるより、それよりもIO待ちのほうがはるかに遅くなるｗ
クラスファイルが多くなるだろうけど、jarで固めるだけだし。
javaとかjvmとかは、C++C＃Rubyみたいにプログラマーよりじゃなくて
実はハードよりの言語（と仕様）だったりする。
確かゴスリン(BGGA)もやる気みたいだったし、あとはjdk1.7に間に合うかどうかだろう。
クロージャは1.7の目玉だしな。
224:デフォルトの名無しさん
08/02/24 22:56:34
>>220
それ、何をしたいのかやりたいことは分かるが、そもそもJavaと関係ないだろｗ
225:デフォルトの名無しさん
08/02/24 23:06:29
>>217
匿名クラスがjavaのクロージャなんだけど、
そのクロージャってなんだよｗ
226:デフォルトの名無しさん
08/02/24 23:09:26
java.util.concurrent
GUI使わない案件なら、やっぱりJavaはこれでしょ。
クロージャのほうが先に導入されてるとそれなりに面白かったけど。
227:デフォルトの名無しさん
08/02/24 23:14:33
>>225
匿名クラスがクロージャそのものなのはC#なんでは？
228:デフォルトの名無しさん
08/02/24 23:15:46
>>220
それだけダラダラとタイプ量があるなら匿名クラスと同じ。
ていうか、匿名クラスならまだjavaだけど、それjsだろ。
いつも書いてて絶対に必要になるし、ダラダラ書くの面倒じゃん？ってのが始まりだろう。
229:デフォルトの名無しさん
08/02/24 23:17:51
>>218
俺には「C言語はアセンブリのマクロにすぎないから不要」ってぐらい暴論に聞こえるんだが。
クロージャにしたって、一塊の処理の手続きを「ひとつのオブジェクトでもある」のと「データとは異なるものとしてコンパイラに特別扱いしてもらう」のうち後者以外はすべて異端って扱いはどうなのよ。
230:デフォルトの名無しさん
08/02/24 23:24:33
>>227
C#のクロージャの話をしたいのか。
231:デフォルトの名無しさん
08/02/24 23:26:33
>>229
なかなかの暴論だなｗ
オレには「アセンブリは、所詮はCのベンダー実装に過ぎない」って思ってたけどｗ
232:デフォルトの名無しさん
08/02/24 23:27:24
withLock(lock, {=>
System.out.println("hello");
});
withLock(lock) {
System.out.println("hello");
}
あたりは本当にいろいろと可能性が広がりそうで楽しみ。
Collectionも引数にクロージャ渡すものがかなり拡張されるだろうね。
233:デフォルトの名無しさん
08/02/24 23:28:04
>>230
C#スレでやれよ。
234:デフォルトの名無しさん
08/02/24 23:30:08
>>229
何を実現したいのかと、それをどうやるのかの実装とは、別にして考えてみたらどうだ？
それなら全て異端ってことじゃなく、両立可能だろうな。
235:デフォルトの名無しさん
08/02/24 23:38:09
>>232
Collectionには手を出さないんじゃないか？
ジネリクスと混じってしまってパッと見なんだか分からなくなる。
ジネリクスは目が慣れるまで少し時間がかかったしｗ
コンカレント辺りのブロッキングキュー・クラスとかでやるならまだしも。
236:デフォルトの名無しさん
08/02/24 23:40:35
俺はGenericsは単純すぎて拍子抜けした。
C++使いからみれば単純この上ない。
237:デフォルトの名無しさん
08/02/24 23:54:25
C++が意味不明なんだよ。
それもジェネリクスじゃなくて、C++はテンプレートだろ。
C++のやりたいことは雛形プログラム手法で、Java総称型なんだけど、その様子だと分かってないな。
238:デフォルトの名無しさん
08/02/24 23:59:23
>>220
それ、クロージャじゃなくてevalじゃん。
239:デフォルトの名無しさん
08/02/25 00:02:44
ちなみにおまいらクロージャ候補はどの候補がいいと思うよ？
240:デフォルトの名無しさん
08/02/25 00:10:35
>>238
クロージャーであることが目的になっちゃってるの？
241:デフォルトの名無しさん
08/02/25 00:13:49
>>240
evalだと静的に色々解析できないじゃん
242:デフォルトの名無しさん
08/02/25 00:20:02
内部イテレータが欲しい俺は少数派か？
243:デフォルトの名無しさん
08/02/25 00:23:33
↑具体的にどういうコードになるの？
244:デフォルトの名無しさん
08/02/25 00:24:35
>>240
少なくともevalを多用するのは嫌い。
evalは(たとえ動的言語であっても)最後の武器だと思ってる。
245:デフォルトの名無しさん
08/02/25 00:25:11
2ch は保守派 (というか優位に立ちたい人) しかいないからわざわざ披露しない方が良いよ。
246:デフォルトの名無しさん
08/02/25 00:30:15
html出身の人にはクロージャの意味は分からんのです。
247:デフォルトの名無しさん
08/02/25 00:39:00
>>237
C++の方が機能が多いってだけだろ。
C++だってgenericだぜ。
248:デフォルトの名無しさん
08/02/25 00:39:47
>>245
馬鹿は頭固いから何言ってもダメだしな。
なぜこんなスレに来ているのかわからんが。
249:デフォルトの名無しさん
08/02/25 01:02:42
JavaのGenericsを批判している人も批判していない人も、型引数への制約やワイルドカード型引数といった
JavaのGenericsの機能を本当に使いこなせている？
Google作成のGuiceあたりはGenericsを多用しているので、勉強になる。
これらのソースをすらすら理解でき改造できるようになってから、批判しよう。
250:デフォルトの名無しさん
08/02/25 01:08:50
あの程度理解できない人間はこのスレに来るべきじゃないよ
251:デフォルトの名無しさん
08/02/25 01:21:01
clone() じゃねーけど、減らす仕様もロードマップに示して欲しいなー。
@Deprecated じゃないけど 「旧仕様互換ソースはコンパイルできるが新仕様準拠ソースは
コンパイルエラー/ただしランタイムは解決可能」 みたいなアノテーションでも作って。
252:デフォルトの名無しさん
08/02/25 01:37:26
それはコンパイルオプションで解決すりゃいいことでは
253:デフォルトの名無しさん
08/02/25 04:54:50
使う方のソースはそれで良いけど宣言する方のソースはアノテーション必要でしょ。
254:デフォルトの名無しさん
08/02/25 05:55:52
やっぱりC＋＋出身者は、個人的な問題を指摘する事が多いね。
255:デフォルトの名無しさん
08/02/25 09:14:43
cloneって何か変わるの？？
256:デフォルトの名無しさん
08/02/25 14:10:28
>>245
だれだおまえ？
257:デフォルトの名無しさん
08/02/25 21:27:34
私の名はクリストファー・エリクソン。
258:デフォルトの名無しさん
08/02/25 21:28:14
よう！くりちゃん！！久しぶり！！
259:デフォルトの名無しさん
08/02/25 22:15:22
>>250
ずいぶんと自信過剰ですな。
ところでJVMの実装とかあなたはできるんですか？
260:デフォルトの名無しさん
08/02/25 23:09:49
>>222
おまえはだれだ？
261:デフォルトの名無しさん
08/02/26 00:19:24
ボクハ、オンガクカ、デンタクカタテニ
262:デフォルトの名無しさん
08/02/26 00:28:42
もうjava2Kでいいじゃん
263:デフォルトの名無しさん
08/02/26 00:46:08
>>259
GenericsとJVM実装って全然別やん…
264:デフォルトの名無しさん
08/02/26 00:55:26
なんか、味噌でも糞でもとにかく延々と追加して行かなければいけないような雰囲気だねー。
マッチポンプで仕事作ってるようも見える。
265:デフォルトの名無しさん
08/02/26 02:46:25
C＃がね。
266:デフォルトの名無しさん
08/02/26 02:51:58
clone()ってなくなるの？
267:デフォルトの名無しさん
08/02/26 07:47:39
珍妙なもんを削る方向にも進めということでしょ。
268:デフォルトの名無しさん
08/02/26 09:27:53
チンチンを削ちゃうの？
269:デフォルトの名無しさん
08/02/26 09:27:55
>>266
今更削除できないと思うが。
270:デフォルトの名無しさん
08/02/26 09:47:04
clone削除されたら困るんだが
271:デフォルトの名無しさん
08/02/26 10:05:15
されないw
272:デフォルトの名無しさん
08/02/26 11:57:23
やっぱり小さいチンチンは削除です
273:デフォルトの名無しさん
08/02/26 14:30:54
>>245
全く何を言いたいのか意味不明なんだが、もっと分かりやすく書き直してくれないか？
274:デフォルトの名無しさん
08/02/26 20:17:29
>>268
尖らすの？
275:デフォルトの名無しさん
08/02/26 23:06:10
ちぎり取るんだろ
276:デフォルトの名無しさん
08/02/27 00:32:49
結局プロパティってなくなったの？
boundのダウンキャスト地獄な仕様みた瞬間うんざりしたからいらんけど。
277:デフォルトの名無しさん
08/02/27 00:44:36
getter/setterでいいよな別に。
アクセッサの表記にget/setがなくなる程度のメリットしかない気がする。
278:デフォルトの名無しさん
08/02/27 00:53:16
ワンモアセッ！
279:デフォルトの名無しさん
08/02/27 01:34:49
>>277
例えばどうやるの？
280:デフォルトの名無しさん
08/02/27 01:40:24
Property Spec (draft 3)の次ってあるの？
ぐぐってもv4とかなさげなんだけど
281:デフォルトの名無しさん
08/02/27 01:50:35
Seasarのpublicフィールドみたいなことを
勝手にやられるより、あったほうが良いんじゃないか？
282:デフォルトの名無しさん
08/02/27 01:58:51
どうなんの?
何かアノテーションとコンパイラのサポートで十分な気がするけどこれも言語仕様変える気?
283:デフォルトの名無しさん
08/02/27 03:34:44
プロパティなんてメソッド経由のアクセスで十分だろ。なに必死になってんのｗ
284:デフォルトの名無しさん
08/02/27 04:06:28
clone()がどうとうかこうとかも、意味不明なことをいう変質者が多いな。
285:デフォルトの名無しさん
08/02/27 05:19:15
ああ。なんだか何いってんのかわかんない奴が最近多いよ。
やっぱ春だな
286:デフォルトの名無しさん
08/02/27 10:43:09
プロパティはもう入らないんじゃないかな。
クロージャは入るだろうけど。
>>232のような制御構造に近い記述のメリットが大きいから。
並列とか制御に関するクラスの記述に便利だしね。
287:デフォルトの名無しさん
08/02/27 10:46:12
やっぱ、break, returnだろ。
てか、偶然に速レスになってるし。
288:デフォルトの名無しさん
08/02/27 14:56:53
プロパティとかクロージャとかどうでもいいから
XMLリテラルとソースファイルのエンコード指定と
RAW文字列？みたいな今不便なところを改善する機能をはやく取り入れてほしい
289:デフォルトの名無しさん
08/02/27 16:20:49
XMLリテラルはXjが最有力と言われた時期もあったけど、
もう入らないと思う。最近続報が全くないので。当時の賛否を考えると、
here documentであることよりもXMLであることがネックになってると思われ
290:デフォルトの名無しさん
08/02/27 16:54:45
ヒアドキュメントより文字列リテラルに変数変数埋め込めるようにして欲しい。
+結合だと冗長になる。
291:デフォルトの名無しさん
08/02/27 21:17:53
そういう機能作ると半分の人間が動的に作成した文字列に値が入らないか心配しはじめるだろう。
292:デフォルトの名無しさん
08/02/27 21:21:11
変数変数って何よ？
293:デフォルトの名無しさん
08/02/28 00:16:52
XMLリテラルとか変数変数とか向こうで要望出したらどうだ？（当然英語だけどｗ）
294:デフォルトの名無しさん
08/02/28 06:07:06
ようはEL式風のヒアドキュメントがあればHappyってこったな
295:デフォルトの名無しさん
08/02/28 22:47:11
null代入を禁止する型が欲しい。
契約プログラミングまでいかなくていいので、
派生型としてnull代入を禁止する型がほしい。
296:デフォルトの名無しさん
08/02/28 22:55:28
>>295
FindBugs の @NonNull で我慢
297:デフォルトの名無しさん
08/02/28 22:59:00
>>296
できれば代入操作時にnullが指定されたら動的に例外投げてくれるような仕組みがあるとうれしいんだけどね。
FindBugsのそれはしらなかったよ。使ってみる。
298:デフォルトの名無しさん
08/02/29 04:57:36
このnullについては、ライブラリや言語（仕様）やjvmで解決できる問題じゃないと思うんだが、単んに愚痴をこぼしてるだけ？
299:デフォルトの名無しさん
08/02/29 05:08:38
JVM まで持ち出すなら何でもできるじゃん。
300:デフォルトの名無しさん
08/02/29 05:21:03
正直イラン
301:デフォルトの名無しさん
08/02/29 07:48:05
そしてJavaは「C++Jあヴぁ」となりました。
302:デフォルトの名無しさん
08/02/29 22:48:25
>>298
既存のライブラリを呼ぶときキャストの嵐になるのを覚悟すれば、
null代入可能なものと不可能なものを型システムで区別すること自体は簡単。
Cでいうと、普通のポインタはNULLポインタ型と非NULLポインタ型のunionだと思えばいい。
303:デフォルトの名無しさん
08/02/29 22:58:23
バグ検知のための利便性向上目的でしょ。アスペクソ指向 & アサーション方面からの
アプローチでする話じゃないのかな。String s not null と思いつきで書いてみると、いずれ
テーブルのカラム宣言のようなカオスになりそうだが。
304:デフォルトの名無しさん
08/03/01 00:45:54
俺の欲しいのとしてはこんな感じ：
String! s; s = null; // 文法エラー
String t = null; s = t; // 実行時エラー
public void hoge(final String! s){
s.~~(); // 絶対にNullPointerExceptionがおこらない
}
class Hoge<T!>{ }
List<Object!> o = anotherList; // 要素がnullでもとおっちゃうなあ…
305:デフォルトの名無しさん
08/03/01 00:54:30
こんな保守的なところでアイディアを披露しても時間の無駄だよ。
JCP のケツ追いしかできない連中が集まってるところだから。
306:デフォルトの名無しさん
08/03/01 01:24:46
アノテーションで十分だろ
307:デフォルトの名無しさん
08/03/01 01:45:19
>>305
JCPになりようもない愚論を大声で喚いている奴より、
JCP追うだけの奴の方がずっとましで有益です。
308:デフォルトの名無しさん
08/03/01 01:48:34
自覚はあるようですね。
309:デフォルトの名無しさん
08/03/01 02:51:28
英語読むのも書くのも面倒くさいんじゃ
310:デフォルトの名無しさん
08/03/01 04:37:53
nullについてはtry catchでナルポ補足いいんだろ。
また俺様仕様のC＋＋の癖が出でるねｗ
311:デフォルトの名無しさん
08/03/01 04:52:33
「こんな保守的」ってのは
どうしてこういう発想になるんだろう？
312:デフォルトの名無しさん
08/03/01 09:54:18
>>304
String! s; //<この時点でエラーじゃねーのか？
あと、nullを代入する時点で実行時エラーにするのは、パフォーマンス的にムリ。
setX(X x) { if (x == null) throw NullPointerException("X is not nullable"); this.x = x; }
とかしとけ。
313:デフォルトの名無しさん
08/03/01 10:30:55
operator overloadがあれば可能だけど、
nullを代入してはいけないのに、してしまうなんてださいコードだね。
314:デフォルトの名無しさん
08/03/01 10:32:55
大抵こういう流れになります。
315:デフォルトの名無しさん
08/03/01 11:00:36
>>313
Javaみたいな静的型言語だと、operator overload を使って null 代入チェックしようとすると
クラス単位で null代入可能か不可能かを決めなくちゃいけなくなって逆に不便なような気もするが。
316:デフォルトの名無しさん
08/03/01 11:31:55
でもやっぱりnonnull欲しいよなあ。言語仕様的に。何だっけ？ぷりえんぷてぃぶとか言うんだっけ？
Curlとか触ってると、ホントこれはいいアイデアだと思える。
317:デフォルトの名無しさん
08/03/01 11:34:22
null代入で実行時エラー？
そんな糞仕様は勘弁してくれ
318:デフォルトの名無しさん
08/03/01 11:41:45
>>317
なんでも静的にやろうとするとリフレクション経由で弄った時に簡単に破綻するような。
319:デフォルトの名無しさん
08/03/01 11:51:51
>>316
つ JSR-305
320:デフォルトの名無しさん
08/03/01 12:06:26
要するに @NonNull > JSR-305
321:デフォルトの名無しさん
08/03/01 12:07:40
@CheckForNullってのもある
322:デフォルトの名無しさん
08/03/01 12:11:04
@NetHome
323:デフォルトの名無しさん
08/03/01 12:33:39
そういうのはそもそも設計上の問題じゃないのか？
324:デフォルトの名無しさん
08/03/01 12:41:26
debug用annotationだし。> 305
言語にいれろって言っている奴は馬鹿だし。>>304
325:デフォルトの名無しさん
08/03/01 12:50:12
NullPointerExceptionとassertを使い分ければいいだけだからいらんな
326:デフォルトの名無しさん
08/03/01 13:02:14
AspectJかJavassist使えばいいんじゃね？
327:デフォルトの名無しさん
08/03/01 14:03:41
多分、奴の頭の中では「C++じゃヴぁ」を考えてるんだろうｗ
328:デフォルトの名無しさん
08/03/01 14:10:19
>>307
よう、この流れのどこが有益なんだ？
329:デフォルトの名無しさん
08/03/01 14:21:08
粘着ｷﾀｰw
330:デフォルトの名無しさん
08/03/01 14:30:45
自意識過剰すぎ
331:デフォルトの名無しさん
08/03/01 14:36:25
思いつきをここに書き込むことでJavaをよりよくしてくださって本当にありがとうございました
332:デフォルトの名無しさん
08/03/01 20:42:27
こういう連中がいることでオタクが嫌われるんだろうなあ
333:デフォルトの名無しさん
08/03/02 03:30:15
いい加減、みんなの夢を詰め込んだJava3を作ってくれないかな？
そしてぶちぎれた誰かが、FreeJavaとかNetJavaとか作ればいいと思うお。(*´∀`)
334:デフォルトの名無しさん
08/03/02 03:36:30
SunがJavaと呼称するのは禁止させるだろ。
335:デフォルトの名無しさん
08/03/02 03:37:45
そんなことしなくても既に JCP が輪姦中じゃん。
336:デフォルトの名無しさん
08/03/02 06:43:25
>>333
Java OSとかOpenJavaがないのはネタ？
337:デフォルトの名無しさん
08/03/02 06:44:57
というか、Javaというのは言語とライブラリ群であって、
実体はjvm用のバイトコードを生成するコンパイラなんだけど。
だから好きなだけJRubyとかJC++とかJC99とかのコンパイラ作れよｗ
（多分君らのようなMSーC＋＋厨じゃ無理だろうけどｗｗ）
338:デフォルトの名無しさん
08/03/02 10:37:54
実体とかアホじゃないの？
339:デフォルトの名無しさん
08/03/02 10:42:33
アホだな。
JVMやバイトコードの仕様拡張を含むJCPの議論を知らない知ったか厨だろ。
340:デフォルトの名無しさん
08/03/02 11:17:14
>バイトコードの仕様拡張を含む...
ずっと昔から議論されてるみたいだけど、どの程度すすんでるの？
341:デフォルトの名無しさん
08/03/02 11:23:42
>>338-339
また湧いてきたｗ
もう春かｗｗ
342:デフォルトの名無しさん
08/03/02 11:43:23
wを多用するとバカっぽいのは分かった。
343:デフォルトの名無しさん
08/03/02 11:52:59
今頃そんな事分かったのか…
344:デフォルトの名無しさん
08/03/02 12:10:31
アノテーションのためにクラス・ファイルが拡張されたのを勘違いしてるんだろ
345:デフォルトの名無しさん
08/03/02 12:15:59
ハァ？おまえが勘違いしてね？
346:デフォルトの名無しさん
08/03/02 14:33:29
javaはプラットフォーム一式なんだが
347:デフォルトの名無しさん
08/03/02 15:52:59
JavaScript, JRubyとかはどうなるんだ？
348:デフォルトの名無しさん
08/03/02 15:53:55
厨房がこのスレに潜伏中の模様！注意せよ！！
349:デフォルトの名無しさん
08/03/02 16:26:35
社員じゃなくてバイトがコード書いてるの？
350:デフォルトの名無しさん
08/03/02 16:49:33
マイクロソフトの下請けとかそうんかんじらしいよｗ
351:デフォルトの名無しさん
08/03/02 18:53:33
＞アノテーションのためにクラス・ファイルが拡張されたのを勘違いしてるんだろ
はぁ？アホじゃねぇの？
アノテーションはバイトコード内の属性用のブロックに格納されますが？
352:デフォルトの名無しさん
08/03/02 19:12:06
何で「あなた」ごときがそれを知ってるんですか？
353:デフォルトの名無しさん
08/03/02 19:22:11
厳密にいうとバイトコード内ではなくてクラスファイル内というべきだが
クラスファイルの仕様は公開されてるんだから調べればわかる
URLﾘﾝｸ(java.sun.com)
354:デフォルトの名無しさん
08/03/02 20:09:57
アホテーションはどこに格納されてますか？
355:デフォルトの名無しさん
08/03/02 21:08:32
お前の頭の中にあるんじゃねーのか？
356:デフォルトの名無しさん
08/03/02 21:59:15
>>353
何で「あなた」ごときがそれを知ってるんですか？
357:デフォルトの名無しさん
08/03/02 22:00:49
>>351はアホだね。
358:デフォルトの名無しさん
08/03/02 22:41:20
おいおい、ほかの言語にももっと目を向けろよ。
Not Nullにする構文がどんだけ有益なことかわからんのか。
359:デフォルトの名無しさん
08/03/02 22:43:26
>>358
せまい世界の問題に何を必死になってんだか
360:デフォルトの名無しさん
08/03/02 23:13:24
じゃあJavaは今のままで問題ないとでも？
361:デフォルトの名無しさん
08/03/02 23:14:41
>>325
362:デフォルトの名無しさん
08/03/02 23:50:07
ぬるぽ
363:デフォルトの名無しさん
08/03/03 04:32:20
そんな考えだから衰退していくんだ
364:デフォルトの名無しさん
08/03/03 04:42:11
だからこんなところで発案するだけ無駄だと言ったろう。
お上から落ちてきた仕様書の解釈論程度の能力しかない下請け連中が集まってるだけなんだから。
365:デフォルトの名無しさん
08/03/03 06:41:33
>>363
というかおまえはJavaa使うな。
おまえはJavaaで何が作れて、Javaaに何期待してるんだ？
吠えてるだけで何も作れない奴はこのあたりで黙っちゃうだがなｗｗｗん？
366:デフォルトの名無しさん
08/03/03 07:29:46
それが良いアイデアだと妄信してる時点で終わってるでしょ
見た目をちょっと変えるだけで何の革新でもないし、
コーディングスタイルの歪な文化をひとつ増やすだけでも迷惑。
367:デフォルトの名無しさん
08/03/03 07:37:40
それはアノテーションのことかクロージャーのことか、どれの事言ってんだ?
368:デフォルトの名無しさん
08/03/03 08:14:48
Java学習暦2ヶ月の厨房が吠えてるんでしょうｗ春だしｗ
369:デフォルトの名無しさん
08/03/03 09:01:12
------------- ここまでテンプレ -------------
370:デフォルトの名無しさん
08/03/03 09:28:05
----------- ここからプロローグ -----------
371:デフォルトの名無しさん
08/03/03 21:16:39
>>366
そうではない。
進化をとめた言語は、死んだも同然。
C++を見てみろ。
372:デフォルトの名無しさん
08/03/03 21:18:17
C++は革新だらけの言語だが…
むしろ革新多すぎw
373:デフォルトの名無しさん
08/03/03 21:24:41
C++0x はどうせ VC++ で実装されないと踏んでるのですね。
ありえそうで怖い。
374:デフォルトの名無しさん
08/03/03 21:29:16
C99はいつになったら
375:デフォルトの名無しさん
08/03/03 21:34:49
C++だって糞みたいな提案は拒否されてる。>>366に同意。
376:デフォルトの名無しさん
08/03/03 21:41:01
お前らごときが何エラそうに評価してんだｗ
377:デフォルトの名無しさん
08/03/03 21:43:52
お前ごときが口出しするな
378:デフォルトの名無しさん
08/03/03 21:48:45
ﾌﾟｯ
2ch で吠えるなよ～ ｷｬﾝｷｬﾝｗ
379:デフォルトの名無しさん
08/03/03 22:05:32
じゃこのスレいらないね
380:デフォルトの名無しさん
08/03/03 22:06:21
>>374
GCC拡張で良いんじゃね？
381:デフォルトの名無しさん
08/03/03 22:08:53
VCで実装うんちゃらとかいってる時点で厨房だろｗｗｗｗここJava擦れだしｗｗ
花見気分で様子見してろよｗｗｗｗ分かるからｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
382:デフォルトの名無しさん
08/03/03 22:15:39
厨房注意報出てるんだから、スルーしろよ
といってもこのスレの住人レベルじゃ無理だろうけどｗ
383:デフォルトの名無しさん
08/03/03 23:17:29
NonNullとかでガチガチにしても結局たいして意味ないんだよな
384:デフォルトの名無しさん
08/03/04 00:44:12
ヌルポが回避できたって、テキトーな初期値が入れられるだけなんだったら意味無いからな。
それなら、ヌルポ出して、その変数に入れるべき値を考察させればいい。
385:デフォルトの名無しさん
08/03/04 02:36:17
ラムダがint hoge => hoge という形になると
Javaは生涯C#に追いつけないことが確定するからな
386:デフォルトの名無しさん
08/03/04 07:24:02
>>380
いつになったらVLAを関数に渡せるようになるの
387:デフォルトの名無しさん
08/03/04 08:10:47
未だにJavaとMS（VC++VBC#)を比べてるガキがいる件について語ろうではないか
388:デフォルトの名無しさん
08/03/04 11:23:39
Javaは一生懸命C#に追いつこうと機能追加しとるじゃない
389:デフォルトの名無しさん
08/03/04 11:28:39
ちなみにプロパティも属性もボクシングもC#は1.0からもってる
クロージャは2.0で持ってる
今は3.0ね
390:デフォルトの名無しさん
08/03/04 11:44:16
ニートはこんなすれに粘着してないで早く面接行けよｗ
391:デフォルトの名無しさん
08/03/04 18:40:02
C#のプロジェクトって早くもデスマってるのが多いよ
392:デフォルトの名無しさん
08/03/04 18:45:28
C#は始めから迷走してるからな。何がやりたいのか分からん
393:デフォルトの名無しさん
08/03/04 18:53:44
>>391
このスレ関係ないし、まったく興味ないから知らないな。
例えばどれ？
394:デフォルトの名無しさん
08/03/04 19:04:03
>>393
関係ないといいつつ話を継続させようとするな
395:デフォルトの名無しさん
08/03/04 19:14:50
じゃ、はよ消えてくんろ
396:デフォルトの名無しさん
08/03/04 19:34:36
>>393
馬鹿かおまいはｗ
397:デフォルトの名無しさん
08/03/04 19:45:52
今IT業界ではJavaこそが諸悪の根源とされてるのを知らんのか
398:デフォルトの名無しさん
08/03/04 19:53:58
いやおまいらみたいな無能労働層だろｊｋ
399:デフォルトの名無しさん
08/03/04 19:56:38
>>392
C#は1.0の時から3.0の機能は全部予定してたから今のところ何の破綻もない
一直線だ
むしろ迷走してるのはJavaだな
言語仕様を民主的に決める必要なんてかけらも無いのに
400:デフォルトの名無しさん
08/03/04 20:02:23
Javaは方向性も、ビジョンもないからな。
ほんと、これからどうして行きたいのかがわからん
401:デフォルトの名無しさん
08/03/04 21:58:06
このC#厨房は何をしにきたたたたたたたたんだ？
402:デフォルトの名無しさん
08/03/04 22:01:41
自慢しに来た
403:デフォルトの名無しさん
08/03/04 22:06:36
まあ実際、近視眼的な部分はあるよ。
JCPはとどのつまり企業連合な組織だし。
EE6でSpringやS2が壊滅したらちょっと面白い。
404:デフォルトの名無しさん
08/03/04 22:48:56
まぁ、いまのところEE勢が壊滅した事しかないのが笑えるよな。
405:デフォルトの名無しさん
08/03/04 23:05:31
なんかunrestricted closureも実装してきているなあ。> BGGA実装
jsr166z.forkjoinもかなりいろいろ増えてるし。
Control invocation syntaxが楽しくてたまらん(ﾊｧﾊｧ
406:デフォルトの名無しさん
08/03/04 23:12:13
クロージャは次期採用はほぼ固まったみたいでもう追いかけてないんだけど、どお、便利？
407:デフォルトの名無しさん
08/03/05 00:27:08
無名内部クラスがあるのにクロージャも作るのか
408:デフォルトの名無しさん
08/03/05 02:34:54
>>406
import java.util.*;
enum s { This, is, a, test; };
public class I {
public static void eachEntry(List<s> l, { s ==>void } block) {
for (s i : l) {
block.invoke(i);
}
}
public static void main(String[] args) {
List<s> l = Arrays.asList(s.values());
for (s i : l) {
System.out.println(i);
}
eachEntry(s i: l) {
System.out.println(i);
}
}
}
409:デフォルトの名無しさん
08/03/05 10:09:05
ruby使ってる奴らは未だにクロージャとイテレーターの区別ついてないだろうけど。
javaやるとクロージャはどういうのかがやっと理解できるのかもな。
410:デフォルトの名無しさん
08/03/05 10:11:44
連中にクロージャなんて意識ないだろ？
411:デフォルトの名無しさん
08/03/05 10:21:06
レスはえーなｗ
javaの連中もイベント処理でクロージャ（匿名クラス）使ってるって意識はないだろう
イテレータよりは匿名クラス・デリゲートｗのほうがクロージャっぽいけど、まあどっちも同じだ
で、使ってみた感想は将来有望とか利用できるアイディアはいろいろ浮かんでくるか？
412:デフォルトの名無しさん
08/03/05 17:31:20
もうJavaはすててScalaでいいんじゃね？
413:デフォルトの名無しさん
08/03/05 18:35:20
俺はrhino派だな。手続き型+OOP+関数型のマルチパラダイムは便利だ。
414:デフォルトの名無しさん
08/03/05 18:36:24
クロージャと匿名クラスは違う
ローカル変数をクロージャが実行される時まで取っておくのが
クロージャの性質だ
415:デフォルトの名無しさん
08/03/05 18:37:18
final 宣言すりゃとっておけるじゃん。
416:デフォルトの名無しさん
08/03/05 18:53:02
たとえばオープンした後自動的にクローズするような処理にもクロージャは便利だ
new File(path).Read(Input in){
...
}
ブロックを抜けたあと勝手にCloseしてくれるようにできる
417:デフォルトの名無しさん
08/03/05 19:05:43
>>414
interface Guess{ int guess(); }
class Fuga{
static Guess hoge(final int i){
return new Guess(){ public int guess(){ return i; } };
}}
個人的にはイテレータとか作るときに使う。
418:デフォルトの名無しさん
08/03/05 23:38:12
>>414>>415
サンプル実装では、
・@Sharedアノテーションを付けた変数は、バインディングがヒープに作られ、
スコープ内にあるクロージャで持ち運ぶ事ができる。書き換えても結果が共有される。
(スティール大先生のクロージャ・コメントの通りの仕様
暗黙のヒープ確保はしないのがJava流)
・BGGA v0.5の通り、finalな変数は持ち運べる。
の両方が可能。
v0.6が出て、@Sharedに相当する修飾子が出来るのかどうか、
その辺の議論はまだ追えてません。個人的には、
Java7はv0.5の仕様のままで、Java8まで持ち越した方がいいような気がします。
先に解決すべき「Open Issues」があるように思うので。
Doug Lea大先生のjsr166y fork-join frameworkがこなれてきてから、
並列実行での"shared"も同時に解決するようなスキームが望ましいと思うので。
419:デフォルトの名無しさん
08/03/05 23:41:19
>>405
> Control invocation syntaxが楽しくてたまらん(ﾊｧﾊｧ
構造化プログラミングでいうところの構造的な制御構造は何でも作れますね。
ifとかwhileとか。
継続とtail jumpがないから非構造的な制御構造は無理だけど。
ただサンプル実装では、>>405の通り、
returnでクロージャの外の関数を出られる実装が出てきそうだけど。
420:デフォルトの名無しさん
08/03/05 23:50:11
参照渡しはまだかね。
421:デフォルトの名無しさん
08/03/05 23:53:00
finalな変数だけ運べれば十分な気がするな
普通の変数を突っ込まなきゃならないケースが思いつかないし
ややこしくて危険でもある気がする
422:デフォルトの名無しさん
08/03/05 23:54:18
finalじゃなくても適当にfinalを仮定してくれればいいやー
423:デフォルトの名無しさん
08/03/05 23:57:14
ローカル変数がスコープ外の影響受けるなんてのは漏洩の副作用と言った方が良い。
リターンバッファのようにあからさまに意図したものならともかく。
424:デフォルトの名無しさん
08/03/05 23:58:33
アノテーションにまで手を伸ばすのは止めて欲しいな。
こんなんじゃXML hellがAnnotation hellに置き換わるだけだ。
425:デフォルトの名無しさん
08/03/06 00:13:42
全く。
アノテーションは、プログラムに付ける付箋紙のような役割から
ロジックと複雑に絡み合ったカオスの元になりつつあるな。
プログラム的な定義は、言語として定義してくれ。
@Shared アノテーションは、アノテーションの誤用としか思えない。
426:デフォルトの名無しさん
08/03/06 00:24:43
勝手な言語拡張をするんじゃなくて、
処理系独自の意味を与えられる(Cの#pragmaのように)
アノテーションを使っているだけだと思います。
もし必要だということになれば、修飾子になるのでしょう。
Doug Lee大先生が今この辺りのことをどうしているかは追えてないです。
ただ並列に動いているクロージャ同士が、
「環境」を共有しているって状況はとても自然で、応用によっては有益なので、
full closureはいつか入るだろうし、また入るべきだと思います。
427:デフォルトの名無しさん
08/03/06 00:26:23
>>425
サンプル実装と仕様提案を混同して議論しないようにしましょう。
>>418に書いたのはサンプル実装のことで、
@Sharedを使うなんて提案は全くありません。
428:デフォルトの名無しさん
08/03/06 00:27:13
Swing App frameworkのActionアノテーションも間違ってる気がする
429:デフォルトの名無しさん
08/03/06 00:31:41
環境といえば、JSR-323が否決されてたような。
430:デフォルトの名無しさん
08/03/06 00:35:45
試行錯誤中だし、戯言に付き合うのも程ほどにｗ
431:デフォルトの名無しさん
08/03/06 00:39:37
JSR-323って、サマリを見たら昔流行った
MobileAgent系の話のように見えるけど、なんでOS仮想化技術が出てくるんだろう・・・？
Voteのコメントが、何か学生の研究に対するコメントのようで笑えてしまった。
432:デフォルトの名無しさん
08/03/06 00:39:54
List<Action> list = new List<Action>();
for(int i = 0; i < 10; ++i)
{
list.Add( () => Console.WriteLine(i) );
}
foreach(Action action in list)
{
action();
}
これがC#では 10,10,10...と10が10回繰り返される。
finalを付けなきゃいけない場合は
for(int i = 0; i < 10; ++i)
{
final int x = i;
list.Add( () => Console.WriteLine(x) );
}
こうすると0,1,2,3,4...と狙ったような結果になってくれる
まあC#にはfinalないけど
433:デフォルトの名無しさん
08/03/06 00:53:29
歴史的クロージャ
434:デフォルトの名無しさん
08/03/06 00:58:50
>>431
あそこで言っている仮想化は、
OSに対して行う仮想化じゃなくて、
OSがリソースに対して行う仮想化。
例えば、JavaにIPアドレスをmobile可能にする細工を入れるんじゃなくて、
Mobile IP使えば解決する、まあそんな話。
幾らなんでも早急だったと思うし。研究としては悪くないけど。
435:デフォルトの名無しさん
08/03/06 09:44:35
昔はやっと言うよりも、当時の技術（特にハード）で実用的じゃなくて破棄されたけど、
今なら出来そうだというところが大きいんじゃないか。
次は見た目関数型らしきのも入れて、そんなJavaはsmalltalkとかを中心とした昔の技術の集大成でしかないしｗ
436:デフォルトの名無しさん
08/03/06 09:47:15
昔に流行った
437:デフォルトの名無しさん
08/03/06 10:02:45
>>432
ここは最新追っかけだし、せっかくならJava話をしてC＃の話もついでに披露してくれないか
たとえば、おまえの頭にはMacやLinuxにはすごいハッカーがたくさんいるとか考えた事もないだろ？
438:デフォルトの名無しさん
08/03/06 10:07:22
>>437
何いってんのかわかんねえけど俺はクロージャにはfinalなローカル変数が入れられれば
十分だと思っていて、C#ではfinal以外が入れられることでどういう不都合が起こるかを述べている
439:デフォルトの名無しさん
08/03/06 10:14:16
>>438
>>432って不都合か？ せいぜい「評価されるタイミングが俺の好みじゃない」っつーだけのような。
初心者が使いやすい、あんな記述やこんな記述でトラブルの元になってるとか、
そこらへんまで言わないとfinal以外が入れられると不都合、って話にはならんような。
440:デフォルトの名無しさん
08/03/06 10:14:19
>>437
お前痛いよ
441:デフォルトの名無しさん
08/03/06 11:37:23
>>439
C#の話はいいです。
442:デフォルトの名無しさん
08/03/06 12:05:48
>>441
C#の話じゃないって。
unrestricted closure には、取り囲むスコープの変数なら final も @Shared もなしで取り込める。
443:デフォルトの名無しさん
08/03/06 12:38:30
unrestrictedはJava7には入りそうにないね。
444:デフォルトの名無しさん
08/03/06 13:17:41
結局C＃とかC＋＋の部外者がいると荒れるわけですか
少し花見でもしてたつもりですけど、それなら徹底的に排除するまでですけど？
445:デフォルトの名無しさん
08/03/06 13:25:25
>>437
linux, macの奴らはC#など触ったこともないだろ。
奴らの話を聞くだけで耳が腐るｗ
所詮C＃はドカタ候補専用だしな
446:デフォルトの名無しさん
08/03/06 13:34:48
だから言ってるだろ？C＃厨房の相手なんかするなよｗ
447:デフォルトの名無しさん
08/03/06 13:36:54
>>443
仮に unrestricted が入らなくても @Shared やら、
final int[] みたいに似非参照化すりゃ同じ事ができるわけで。
それにv0.5の仕様には
> All free lexical bindings - that is, lexical bindings not defined within the closure literal -
> are bound at the time of evaluation of the closure literal to their meaning in the lexical context
> in which the closure literal appears.
とかバッチリ書いてあるしなぁ。
unrestrictedが入りそうにないって話も信憑性無いし。
448:デフォルトの名無しさん
08/03/06 13:38:43
そうだな。C＃なんて脳みそはVBの奴らとドッコイなのに、こいつらとJavaを同じにされちゃたまらないな。
いつの時代もMSの奴らはキモイってことだな
449:デフォルトの名無しさん
08/03/06 13:56:44
>>447
javac.infoの実装だと、
unrestrictedは==>で区別することになってますね。
=>はjava.lang.RestrictedFunctionなクロージャ。
450:デフォルトの名無しさん
08/03/06 14:03:34
>>449
それは知ってる。
けど unrestricted 入れないつもりなら unrestricted と restricted の区別なんか必要ないんだから
java.lang.RestrictedFunction 自体要らないでしょ。
451:449
08/03/06 14:04:30
でしょって俺に言われても困るけどねw
452:デフォルトの名無しさん
08/03/06 14:20:49
>>440
おれにはJava最新追っかけスレでC#のことをウダウダ言う奴の方がどう見ても痛い
たぶんおまえの方が痛いｗ
453:デフォルトの名無しさん
08/03/06 14:22:52
C#しか脳がないニートは、はよ面接行けｗｗ
454:デフォルトの名無しさん
08/03/06 14:37:56
MS厨ってどこにでも沸くKYだな
455:デフォルトの名無しさん
08/03/06 14:38:23
> Any visible local variable that is initialized or assigned exactly once in the enclosing scope,
> as well as any visible parameter to an enclosing method that is never otherwise assigned,
> is accessible but not assignable within the body of the CICE, whether or not it is explicitly qualified as final.
CICEのルール、BGGAのプロトタイプに導入されてるね。
456:デフォルトの名無しさん
08/03/06 14:57:51
クロージャ厨房も同じくウザイ
457:デフォルトの名無しさん
08/03/06 15:03:45
あと変更入りそうなのは non-local return と local return あたりかなぁ。
{ => method(); } と { => method() } と、ぱっと見て区別つかん。
458:デフォルトの名無しさん
08/03/06 15:22:52
>>455
@Shared も CICE の↓の public とほとんど同じだし、
いいところはマージしてるんじゃ
public int count = 0;
Arrays.sort(array, Comparator<Integer>(Integer v1, Integer v2){
count++;
return v1.compareTo(v2);
});
System.out.println(count);
459:デフォルトの名無しさん
08/03/06 15:41:22
>>418
今日落としたプロトタイプ実装だと、
@Sharedつけなくても警告がでるだけでコンパイルエラーにならんような
これ、ホームページには updated 2008-02-22 って書いてあるけど、
解凍すると closures-2008-03-05ってディレクトリができる……
コッソリと何か変わってたりするんだろうか？
460:デフォルトの名無しさん
08/03/06 16:36:45
ああ、それなら最近変ったんじゃないかな。> @Sharedいらず
2008-02-26ってのもあるし。
461:デフォルトの名無しさん
08/03/06 19:22:17
2008-02-12 が残ってたから @Shared なしを試してみたけど
警告は出るけどコンパイルエラーにはならなかった。
462:デフォルトの名無しさん
08/03/06 19:37:46
単にコンパイルエラーにするのが面倒なだけじゃね
463:デフォルトの名無しさん
08/03/06 20:12:41
クロージャの話を他の言語で例示しただけでフルボッコされるなんて、
このスレじゃまともな技術的議論はできそうにないな
464:デフォルトの名無しさん
08/03/06 20:27:43
そりゃ保守の集まりでしかないから論議なんかはじめからする気ないんじゃ。
JCP = バチカン、JSR = 教典、それ以外の論議 = 異端 = 叩き、な
ご熱心な殉教者しか居ないのは昔からの事。あ、こりゃ保守というか権威主義か。
465:デフォルトの名無しさん
08/03/06 21:12:55
おまえ毎日同じこといってるな
466:デフォルトの名無しさん
08/03/06 21:14:48
そりゃこんだけ毎度同じパターンばかり見せれるとな。
467:デフォルトの名無しさん
08/03/06 21:26:17
で、Javaのクロージャの場合>>432は
10,10,10...？0,1,2,3,4...？
468:デフォルトの名無しさん
08/03/06 23:18:14
保守の集まりというのは以前も書いてあったけど、一体どういうことだよ。
バチカンとか経典とか、お前頭は相当おかしくなっちまってるようだなｗ
469:デフォルトの名無しさん
08/03/06 23:20:00
C++（C#?)のやりすぎだろ。ストールマンの友達かなんかだろ。たぶん。
470:デフォルトの名無しさん
08/03/06 23:32:55
>>463
技術的な議論とかしたいなら、せめてJavaスレにふさわしくJavaでやれよ。
C＃スレでPHPとかVBとかで議論wとか通用しないのと同じだろ。
これに気がつかないおまえのバカさ加減にあきれるw
471:デフォルトの名無しさん
08/03/06 23:33:08
>>432
それスタックの状態を保存するという考えに基づけば正常な動作じゃないか？
472:デフォルトの名無しさん
08/03/06 23:35:33
>>463
もうおまえはこのスレに来なくていいよ。おまえみたいな奴が一人でもいると、スレが荒れるだけだから。
473:デフォルトの名無しさん
08/03/06 23:37:22
>>464も忘れてたｗ
バチカンとか意味不明な奴もお花畑板いけよw
474:デフォルトの名無しさん
08/03/06 23:39:11
間違えてageちまったじゃねーかよー
どうしてくれるんだ？おい、おまえら！！
>>463-464
おまえら責任とれよな
475:デフォルトの名無しさん
08/03/06 23:40:12
何だこの酔っ払い
476:デフォルトの名無しさん
08/03/06 23:41:22
英語は使えなくても叩くときだけは大張り切りですな。
477:デフォルトの名無しさん
08/03/06 23:48:20
>>464
こういうことは言うのは派遣かニートだろ。
こんな社会のカスは相手にすんなよ。
違うスレでは「ニート達よ団結せよ！」とかいってる奴だからw
478:デフォルトの名無しさん
08/03/06 23:51:25
真・スルー 何もレスせず本当にスルーする。簡単なようで一番難しい。
偽・スルー みんなにスルーを呼びかける。実はスルーできてない。 ← >>477
予告スルー レスしないと予告してからスルーする。
完全スルー スレに参加すること自体を放棄する。
無理スルー 元の話題がないのに必死でスルーを推奨する。滑稽。
失敗スルー 我慢できずにレスしてしまう。後から「暇だから遊んでやった」などと負け惜しみ。
願いスルー 失敗したレスに対してスルーをお願いする。ある意味３匹目。
激突スルー 話題自体がスルーの話に移行してまう。泥沼状態。
疎開スルー 本スレではスルーできたが、他スレでその話題を出してしまう。見つかると滑稽。
乞食スルー 情報だけもらって雑談はスルーする。
質問スルー 質問をスルーして雑談を続ける。
思い出スルー 攻撃中はスルーして、後日その思い出を語る。
真・自演スルー 議論に負けそうな時、ファビョった後に自演でスルーを呼びかける。
偽・自演スルー 誰も釣られないので、願いスルーのふりをする。狙うは４匹目。
３匹目のスルー 直接的にはスルーしてるが、反応した人に反応してしまう。
４匹目のスルー ３匹目に反応する。以降５匹６匹と続き、激突スルーへ。