[Java SE 7] 次世代Javaの動向 6 [dolphin]
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
2008/01/03(木) 12:29:37[Java SE 7] 次世代Javaの動向 5 [dolphin]
http://pc11.2ch.net/test/read.cgi/tech/1178925915
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
http://pc11.2ch.net/test/read.cgi/tech/1163986696/
[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向 ２
http://pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/
0002デフォルトの名無しさん
2008/01/03(木) 12:35:37最近のJavaはどういう言語的要素を取り入れようとしているのか
簡潔に教えてください。
0003デフォルトの名無しさん
2008/01/03(木) 15:21:37・クロージャ（ってMSVJ++のDelegateとどう違うのだか俺にはよくわからんのだが）
あとあとなんだっけ。
0004デフォルトの名無しさん
2008/01/03(木) 15:39:310005デフォルトの名無しさん
2008/01/03(木) 16:18:190006デフォルトの名無しさん
2008/01/03(木) 16:38:12クロージャ追加は濃厚ってこと。
0007デフォルトの名無しさん
2008/01/03(木) 17:11:430008デフォルトの名無しさん
2008/01/03(木) 17:35:27総論としてのクロージャ追加に反対な人たちは少数派みたいだし、
クロージャ追加反対論の先頭に立つ人もいないから、
その意味ではクロージャ追加は濃厚。
ただし、各論としては、オレはアイツの提案のあれが気にくわないって感じでもめてる。
だからクロージャでもめたせいで1.7のリリースが遅れるとか
1.7の機能からクロージャが漏れるとかって事態はありうる。
0009デフォルトの名無しさん
2008/01/03(木) 18:26:260010デフォルトの名無しさん
2008/01/03(木) 18:26:27BGGAだったか、{int a=>a+1;}; でまとまるよ。
その説得ってことだろうｗ
なんなら、ニールのブログに突撃してみたらどうだ？
このスレ的には勇者になれるしw
0011デフォルトの名無しさん
2008/01/03(木) 18:30:17プロパティ
BigDecimalの演算子化
invokedynamic (JVM bytecode)
見た目で感じられて、濃厚なのはこれぐらいかな。
あとアノテーション拡張がどうとか。
0012デフォルトの名無しさん
2008/01/03(木) 18:33:25BigIntegerの演算子かも頼む
0013デフォルトの名無しさん
2008/01/03(木) 18:38:42シンプルさを維持できないとかいう理由でその予定はないらしいが、
だったらString型のシンタックスシュガーもやめろよと思う。
0014デフォルトの名無しさん
2008/01/03(木) 18:53:51C++とJavaは違うってことだｗ
また鼻息あらいようだなｗｗ
0015デフォルトの名無しさん
2008/01/03(木) 18:55:47当然英語はできるんですよね？
0016デフォルトの名無しさん
2008/01/03(木) 19:02:55ALL OR NOTHING な発想は思考停止に等しい。
0017デフォルトの名無しさん
2008/01/03(木) 19:04:510018デフォルトの名無しさん
2008/01/03(木) 19:11:48もしサポートしたら、いろいろすごい事になっちゃうよ。
とうか、もう違う言語かよってぐらいｗ
つまり
演算子オーバーロードが必要な人は大体は行列や複素数程度しか頭にないんだろうけど、
歴史的にはCのプリプロセスの悪夢と似てるんじゃないかｗ
0019デフォルトの名無しさん
2008/01/03(木) 19:14:070020デフォルトの名無しさん
2008/01/03(木) 19:15:02そこで出てる中で、仮にもJSRまでいってるのは
invokedynamic の JSR-292 と、
annotations on Java Types の JSR-308 かな。
プロパティは、JSR-303 とか JSR-295 とかあるけど、
構文糖の方は入るのかよくわからんし。
0021デフォルトの名無しさん
2008/01/03(木) 19:15:29当然英語はできるんですよね？
0022デフォルトの名無しさん
2008/01/03(木) 19:18:12"a" + "b" + "c"
"a".concat("b").concat("c")
よく使うし、普通は上でしょ。
理屈抜きで、プロパティもこれと同じようなことじゃないか。
0023デフォルトの名無しさん
2008/01/03(木) 19:19:140024デフォルトの名無しさん
2008/01/03(木) 19:21:03あれも演算子オーバーロードっちゃ演算子オーバーロードだよなぁ。
0025デフォルトの名無しさん
2008/01/03(木) 19:26:05いや、プロパティの構文糖自体は簡単でもソースの互換性とろうとすると複雑なルールになるから面倒なんよ。
あと、beans仕様全体が性善説的な、みんなで守りましょうねって感じのルールなんで
Java言語仕様みたいな性悪説的なルールとして捉えると穴だらけなんで、そこら辺でも話はややこしくなる。
0026デフォルトの名無しさん
2008/01/03(木) 19:30:23プロパティ
BigDecimalの演算子化
invokedynamic (JVM bytecode) ； JVMで複数の(スクリプト)言語サポートのこと
アノテーション・拡張
ジェネリクス
これだけあれば十分と思うけど。
これ以上が必要となる環境にいないしw
ということで演算子オーバーロードとかはもう過去の話ｗ
個人的には複素数も扱いやすいと数値計算・科学分野・学部生でも、
入門・お気軽プログラムできそうなんだけどね(JavaはGUIサポートしてる)。
個人的には、Javaは平面(GUI)を扱えるから複素数を押したい。
でも今はSUNは、デスクトップの方に力を入れて数値科学のほうは全然だしｗ
0027デフォルトの名無しさん
2008/01/03(木) 19:32:22便利ならいいよ。俺らは策定する方じゃなくて、使うほうだしね。
0028デフォルトの名無しさん
2008/01/03(木) 19:33:500029デフォルトの名無しさん
2008/01/03(木) 19:36:20策定する方も面倒だから簡単にはできねーだろーなっつー話。
プロパティ構文糖のプロトタイプ(?)がkijaroだったかに入ってるけど
あれ旧beansのプロパティと互換性ないでしょ。
0030デフォルトの名無しさん
2008/01/03(木) 19:36:58function typeはモメてる。
0031デフォルトの名無しさん
2008/01/03(木) 19:37:14また宗教ですか？
0032デフォルトの名無しさん
2008/01/03(木) 19:41:270033デフォルトの名無しさん
2008/01/03(木) 19:44:28新機能追加を止めて、バグ取りに専念する期間も必要って事を考えたら
現時点でJSRすら出てない機能は相当遅いと思うけどなぁ。
0034デフォルトの名無しさん
2008/01/03(木) 20:57:08C++の入出力みたいに副作用を演算子で処理するのは違和感があるな。
Immutableなオブジェクトでないと使えないようにするとか……
0035デフォルトの名無しさん
2008/01/03(木) 22:21:45言語仕様レベルでStringやBigDecimalを特別扱いしてやるのがJavaの回答(言語仕様策定者のみが定義できる)。
Javaの言語仕様はプログラマを信頼しない性悪説に基づいているので、自由にやらせろの人にとってみれば悪の化身のような言語にみえるだろうが、初級プログラマが世の中に多い以上こういう言語も必要だ。
Java と Java(Beta) みたいに言語を２つにして１つは初中級向け言語、１つは初中級者向け言語に機能優先で言語仕様を追加した中上級向け言語のようにしてみると、Javaにあの言語仕様入れろとかいう不満は少なくなるように思う。
0036デフォルトの名無しさん
2008/01/03(木) 22:49:26それ、Scala使えって言われて終わりになるよーな。
0037デフォルトの名無しさん
2008/01/03(木) 23:02:540038デフォルトの名無しさん
2008/01/03(木) 23:47:11知ったことではないけどねｗ
0039デフォルトの名無しさん
2008/01/03(木) 23:49:33また宗教ですかｗ
分割するまでもなく、そういう人はruby, javascript でやってよ。
JVMでサポートされるし。
思うに君のような宗教家はJava宗教に向いてないだろうと思う
0040デフォルトの名無しさん
2008/01/03(木) 23:51:27>>35は英語バリバリなんだじょ〜
0041デフォルトの名無しさん
2008/01/04(金) 00:03:510042デフォルトの名無しさん
2008/01/04(金) 00:07:14当然英語はできるんですよね？
0043デフォルトの名無しさん
2008/01/04(金) 00:53:330044デフォルトの名無しさん
2008/01/04(金) 02:09:04別の言語として、Javaのような何かが必要とは思わないけど。
0045デフォルトの名無しさん
2008/01/04(金) 08:08:11http://blogs.sun.com/ahe/entry/java_se_7_wish_list
0046デフォルトの名無しさん
2008/01/04(金) 11:51:230047デフォルトの名無しさん
2008/01/04(金) 11:55:300048デフォルトの名無しさん
2008/01/04(金) 16:08:560049デフォルトの名無しさん
2008/01/04(金) 16:10:22はC, C++, C# の分化した歴史を話してるのだろうかと思った。
0050デフォルトの名無しさん
2008/01/05(土) 00:29:30「当然英語はできるんですよね？」ってどういう経緯で始まったテンプレなんですか？
0051デフォルトの名無しさん
2008/01/05(土) 00:37:49http://pc11.2ch.net/test/read.cgi/tech/1178925915/953-
0052デフォルトの名無しさん
2008/01/05(土) 01:03:32さんくすおあらっと
0053デフォルトの名無しさん
2008/01/05(土) 10:18:450054デフォルトの名無しさん
2008/01/05(土) 20:13:520055デフォルトの名無しさん
2008/01/06(日) 11:34:40APIの翻訳もリリースにあわせて出てるし技術書も翻訳でいいよ。
日常でも英語なくても困ってないし英語いらねー
0056デフォルトの名無しさん
2008/01/06(日) 12:09:13>>35
当然英語はできるんですよね？
0057デフォルトの名無しさん
2008/01/06(日) 14:32:02だいたいみょうちくりんな日本語だなあ、と思う文書は翻訳版だったことが多い。
0058デフォルトの名無しさん
2008/01/07(月) 00:08:39粘着してる人つまんないからもういいよ
0059デフォルトの名無しさん
2008/01/07(月) 00:16:18あたま大丈夫か？
0060デフォルトの名無しさん
2008/01/07(月) 00:19:54新参乙
0061デフォルトの名無しさん
2008/01/07(月) 00:29:51当然英語はできるんですよね？
0062デフォルトの名無しさん
2008/01/07(月) 00:31:220063デフォルトの名無しさん
2008/01/07(月) 01:08:19頑張って勉強したんでみんなを追い越したよー
すごいだろー
0064デフォルトの名無しさん
2008/01/07(月) 17:06:13先逝ったか？ 南無阿弥陀仏。
0065デフォルトの名無しさん
2008/01/08(火) 11:41:540066デフォルトの名無しさん
2008/01/08(火) 17:23:26>>65
当然英語はできるんですよね？
0067デフォルトの名無しさん
2008/01/08(火) 19:51:530068デフォルトの名無しさん
2008/01/08(火) 23:58:590069デフォルトの名無しさん
2008/01/09(水) 00:15:42この動画見ていたらdolphinとか笑えなくなってしまいました（笑）
0070デフォルトの名無しさん
2008/01/09(水) 15:19:470071デフォルトの名無しさん
2008/01/09(水) 20:03:450072デフォルトの名無しさん
2008/01/12(土) 23:32:34public hoge(@Named("foo") int foo,@Named("bar") int bar)みたいに。
0074デフォルトの名無しさん
2008/01/14(月) 15:53:35http://java.sun.com/javase/ja/6/webnotes/ReleaseNotes.html
OGL: フラグメントシェイダーを使用して Linear/RadialGradientPaint を高速化
OGL: フラグメントシェイダーを使用して Convolve/Rescale/LookupOp を高速化
最近は色々な描画エンジンがシェイダー言語を使うようになってきたなぁ。
0075デフォルトの名無しさん
2008/01/14(月) 15:58:480076デフォルトの名無しさん
2008/01/14(月) 16:14:47○ シェーダ
http://ja.wikipedia.org/wiki/%E3%83%94%E3%82%AF%E3%82%BB%E3%83%AB%E3%82%B7%E3%82%A7%E3%83%BC%E3%83%80
0077デフォルトの名無しさん
2008/01/18(金) 02:29:45メタルダーだ
0078デフォルトの名無しさん
2008/01/18(金) 12:54:350079デフォルトの名無しさん
2008/01/18(金) 19:29:350080デフォルトの名無しさん
2008/01/22(火) 08:16:44Rubyですらこれができるようになるのに・・・
0081デフォルトの名無しさん
2008/01/22(火) 08:51:43見りゃ良いし、それってそもそも必要なの? メリットがよう分からん。
0082デフォルトの名無しさん
2008/01/22(火) 09:01:24Firefox 2.0.0.11 Windows版(5.7MB)ダウンロード
http://www.mozilla-japan.org/products/firefox/
IE Tab 1.3.3.20070528 FirefoxをIEエンジンに
https://addons.mozilla.org/ja/firefox/addon/1419
Firefox ＞ ツール ＞ IE Tab のオプション
サイトフィルタ ＞ URL: [http:// ]を入力 [適用] [ＯＫ]
0083デフォルトの名無しさん
2008/01/22(火) 11:05:54それができるのはRubyだからというのはあると思うぞ。
JavaもAPI制限を加えれば、できるかもしれんが
スレッドのアプリごとの分離やそのリソース配分をどうするかっていう問題とか色々ある。
Zoneで使ったような解決方法でいいと思うんだけどね。
で、起動のオプションでMVMで動かすかシングルで動かすかを
指定できればいいのかな。
メリットは、ユーザが頭を悩まさずに使えるか、という部分だろ。
クラスローダ単位とかは、ちょっとテクニカルすぎる。
0084デフォルトの名無しさん
2008/01/22(火) 11:46:12複数のアプリケーションが独立して動くのはアプリケーションサーバで普通にやってるしょ。
テクニカルも糞も、パーティション(?)ごとに URLClassLoader 作ってそれぞれ main
となるスレッドに適当なクラスの main() か何かを呼び出すだけでしょ。
必要ならパーティション内でスレッドプールでも作ればいい。ライブラリならJakartaにも転がってるし。
まぁブートストラップクラスまで完全分離するのはちょっと無理だし、プロセス内で
仮想化ソフト並みのリソース管理システムでも構築できるってなら話は別だが。
意図が良く分からんので Java よく分かってない人が Ruby ﾏﾝｾｰ しに来て失敗してる
ようにしか見えんのだが。
0085デフォルトの名無しさん
2008/01/22(火) 12:01:46リソース管理とか実現した後の話しだし、ならおまえは仮想化ソフト使えよ
0086デフォルトの名無しさん
2008/01/22(火) 12:01:500087デフォルトの名無しさん
2008/01/22(火) 12:05:260088デフォルトの名無しさん
2008/01/22(火) 12:54:42持てない。これは別プログラムから拡張ライブラリとして Ruby を呼び出しても同じ。
だから Apache の CGI として実行すると一つの VM で全てのリクエストを
こなす構成になり、素人が扱うには挙動がやっかいじゃのう、という話か。
JDK 1.2 以上の JNI 使っての Java 機能呼び出しは同一プロセスで複数 VM 起動もイケます。
--- 愁傷 ---
0089デフォルトの名無しさん
2008/01/22(火) 12:57:31http://en.wikipedia.org/wiki/Application_Isolation_API
http://jp.sun.com/company/Press/release/2008/0110.html
0090デフォルトの名無しさん
2008/01/22(火) 13:02:16バグ持ちのネイティブコード呼び出しへの上手い対応が考えられなかった
からだと聞いたことがある。
Rubyもネイティブコードの呼び出しが出来る以上同じ問題にぶつかると思うけどね。
あるアプリがバグ持ちのネイティブコードを呼び出したとき、
JavaVM/RubyVMの管理するヒープを破壊されたとすると、
VMにホストされている全てのアプリが暴走するといった類の問題に
対する解答を用意することができるのかという所。
ちなみにネイティブコードの呼び出しが行えない携帯向けJavaVMでは、
実用化され既にMVMは普及しているレベル。
JSR 121,Application Isolation API Specificationだとかはどうなるんだろうねぇ。
0091デフォルトの名無しさん
2008/01/22(火) 13:10:210092デフォルトの名無しさん
2008/01/22(火) 13:16:00頑張って研究してくれよ
0093デフォルトの名無しさん
2008/01/22(火) 13:16:36プロセス(タスク)に分離して、OSの保護機構を利用して、
それぞれのVMはプロセス(タスク)間通信で情報をやり取り。
0094デフォルトの名無しさん
2008/01/22(火) 13:29:16素人が口だしするなｗ
0095デフォルトの名無しさん
2008/01/22(火) 13:58:41パイプうんぬんのところは未実装なんだろうけど。
0096デフォルトの名無しさん
2008/01/22(火) 21:46:41それ対策のためにわざわざ RMI→JNI 経由して COBOL 呼ぶ設計をしたことがある。
IBM なんかそういうフォールトトレラントの研究はしてそうだが WebSphere にも実装されてないな。
0097デフォルトの名無しさん
2008/01/23(水) 02:58:02やっぱりそうしたら良かったかなと、自作のプログラム相手に悩んでる。
いまんとこ20日くらいは持つんだが。
使っているのはあるライブラリのJava APIで、そいつがさらにJNIを...というパターン。
009872
2008/02/07(木) 18:52:18pythonみたいにr"\d"とか書ければうれしいです。
0099デフォルトの名無しさん
2008/02/07(木) 19:04:420100デフォルトの名無しさん
2008/02/07(木) 19:36:19XMLリテラルも欲しいな。
0101デフォルトの名無しさん
2008/02/07(木) 20:25:400102デフォルトの名無しさん
2008/02/09(土) 00:50:440103デフォルトの名無しさん
2008/02/09(土) 01:03:18いまのところ聞かない。クロージャでもめてるし、JDK7じゃ望み薄かも？
0104デフォルトの名無しさん
2008/02/09(土) 19:18:14それはサポートされたら地味に嬉しいな。
テンプレート的な文字列とか、正規表現書くとき悩まなくてすむ・・・・
0105デフォルトの名無しさん
2008/02/09(土) 21:01:220106デフォルトの名無しさん
2008/02/10(日) 01:28:32CICE ARM のプロトタイプだそうで。
クロージャ案の中で CICEが一番タイプ量多いんだよなぁ。
ぶっちゃけCICEだけだったら匿名クラスがあるから要らんような。
ARMは欲しいけど。
0107デフォルトの名無しさん
2008/02/10(日) 16:36:05それは欲しい。ソースコードが単体で完結せず、エンコーディングというメタデータが必要なのは痛い。
0108デフォルトの名無しさん
2008/02/10(日) 16:40:520109デフォルトの名無しさん
2008/02/10(日) 17:24:40List<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) });
0110デフォルトの名無しさん
2008/02/10(日) 17:46:12javacもIDEも、デフォルトのエンコーディングが環境依存だし
ソースファイル単位で指定できればかなりありがたいんだけど…
packageの次あたりに
encoding "UTF-8"
みたいに書いて指定出来るといいのになあ。
0111デフォルトの名無しさん
2008/02/10(日) 17:49:36どれも汚ｯﾀﾈｰのな。
0112デフォルトの名無しさん
2008/02/10(日) 18:02:48面白いけど、どれもパッとしない
Javaらしい気持ち悪さ
0113デフォルトの名無しさん
2008/02/10(日) 18:05:58ライブラリレベルの話じゃないんだし。
0114デフォルトの名無しさん
2008/02/10(日) 18:11:35クロージャの事を言ってるなら、
もめてるのは議論してどうこうできるレベルの話じゃないような。
「Javaらしさ」なんて、そんなもん個人個人で違うんだから議論にならんし。
時間かければどうにかなるもんじゃないと思うが。
0115デフォルトの名無しさん
2008/02/10(日) 18:12:310116デフォルトの名無しさん
2008/02/10(日) 18:17:37Stringくらい型推論しろ
0117デフォルトの名無しさん
2008/02/10(日) 18:32:46声のでかい順に嗜好を取り込んだ最小公倍数的仕様が最良になるとは思わないし。
逆にセンスのある一人の天才が作った方がシンプルで良い。
0118デフォルトの名無しさん
2008/02/10(日) 18:39:00C#でも仮引数型の型推論してくれたような。
0119デフォルトの名無しさん
2008/02/10(日) 18:43:23他の部分で型推論を導入する際の一貫性みたいなもんもあるし。
0120デフォルトの名無しさん
2008/02/10(日) 21:54:02変な奴やC#かC++に行ってくれ。
0121デフォルトの名無しさん
2008/02/10(日) 22:09:26さようなら、変な人。。
0122デフォルトの名無しさん
2008/02/10(日) 22:26:23まあいじくられる対象ってのはそういうもんだよね。
0123デフォルトの名無しさん
2008/02/10(日) 22:32:44あまりいい感じにならないんだな。
PL/1, Ada, Common Lispなど。
規格管理だけならいいんだけど。
0124デフォルトの名無しさん
2008/02/10(日) 23:28:46スタンダードさえ勝ち取れば、中身が多少糞なのは 「解釈の問題」 とでも言っておけば
後世まで評価されると言うことを彼らはよく知っている。
0125デフォルトの名無しさん
2008/02/15(金) 09:54:54重要ところが抜けているけど、javaは規格じゃなくてあくまで企業やjavaを活用する団体が管理している。
ISOとか関係ないから、それでは例えが悪くそもそもそれらの言語とは比べられない。
おまえは言語使用とライブラリは分離されているとか、そんなところも見えてないだろｗ
0126デフォルトの名無しさん
2008/02/15(金) 10:29:220127デフォルトの名無しさん
2008/02/15(金) 20:15:06大事なところ指摘してるのが分からないんだね。低脳さんｗ
0128デフォルトの名無しさん
2008/02/15(金) 20:26:540129デフォルトの名無しさん
2008/02/15(金) 20:40:230130デフォルトの名無しさん
2008/02/15(金) 21:29:54EE6の場合だとこれだけの機能を追加するのにいくらかかるという資産までしてるみたいだし。
0131デフォルトの名無しさん
2008/02/15(金) 21:35:360132デフォルトの名無しさん
2008/02/15(金) 23:31:200133デフォルトの名無しさん
2008/02/15(金) 23:31:550134デフォルトの名無しさん
2008/02/15(金) 23:41:16>>123-127のレスには「仕様」のことは触れてないようだが、
どこからそんな指摘が出来るんだ？
ところで英語で言えばカッコいいなどと思ってるなら考え直した方がいいだろう。
0135デフォルトの名無しさん
2008/02/15(金) 23:42:510136デフォルトの名無しさん
2008/02/15(金) 23:44:420137デフォルトの名無しさん
2008/02/15(金) 23:52:250138デフォルトの名無しさん
2008/02/15(金) 23:53:550139デフォルトの名無しさん
2008/02/15(金) 23:54:090140デフォルトの名無しさん
2008/02/15(金) 23:56:46アダルトチルドレンが多すぎ（古館的な意味で）
0141デフォルトの名無しさん
2008/02/15(金) 23:58:120142デフォルトの名無しさん
2008/02/15(金) 23:59:390143デフォルトの名無しさん
2008/02/16(土) 00:02:17こういうループ野郎がねらーそのもの
0144デフォルトの名無しさん
2008/02/16(土) 00:03:490145デフォルトの名無しさん
2008/02/16(土) 00:10:540146デフォルトの名無しさん
2008/02/16(土) 00:17:170147デフォルトの名無しさん
2008/02/16(土) 00:18:370148デフォルトの名無しさん
2008/02/16(土) 00:23:000149デフォルトの名無しさん
2008/02/16(土) 00:24:200150デフォルトの名無しさん
2008/02/16(土) 00:27:54>>142
ゴスちゃん一人がそんな影響力あるわけじゃないから。
言語開発者であった初期だけでなく、
Javaの方向性に大きな影響を与えたけど、
もうそろそろいいでしょ。
0151デフォルトの名無しさん
2008/02/16(土) 00:30:28派閥が出来てる状態で言語仕様に深く関わる機能を盛り込めはしないでしょう。
てかサーフィンしてたらSE7にEJB3が追加されるってブログを見つけた。
Webサービスじゃなくて何故にEJB？
0152デフォルトの名無しさん
2008/02/16(土) 00:54:370153デフォルトの名無しさん
2008/02/16(土) 00:56:180154デフォルトの名無しさん
2008/02/16(土) 01:10:52クロージャに限定すれば、BGGAとかの派閥といってもクロージャの書き方というかリテラルが少し違う程度だろ。
Genericsのようにどこまでテンプレート・プログラムを認めるかと同様に、
クロージャをどこまで広げるかの考え方はあるだろう。
しかし、それを議論していても結局は内部クラス（匿名クラス）でいいのかの議論に戻ってしまうし
とすれば、派閥とかいってもリテラルが簡単か否かの違いでしかない。
それとゴズリン（のUNIXでの貢献も含めて）のそのセンス自体がそのままJavaの思想やセンスになっていると思うんだが？
C#はたいした手間でもないのに何でもリテラルして言語仕様にしたりするけど、正直キモイ。
やっぱりMSはいつまでもハンガリアンだしｗ
0155デフォルトの名無しさん
2008/02/16(土) 01:15:32ブラウザで踊ってるデューク見て感動していた頃の古き良き時代が懐かしい。
0156デフォルトの名無しさん
2008/02/16(土) 01:20:2230人の参加者はCICEに賛成し、
BGGA/FCM+JCAは２４人の賛成を得た。
そして、19人が変更しないことを選 んだ。
http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java
0157デフォルトの名無しさん
2008/02/16(土) 02:25:40追求しすぎてバイアスがかかってるってことに気がついてない。
クロージャの話なのにScalaとか勧めてるし、多分バカなんだろ。
クロージャってのは中途半端な内部クラスの設計を、さらに拡張して完成させる程度でしかないだろうな。
C++のtemplateかと思ってたらgenericsは思ってたのと全然違ってたし、
クロージャもアレコレ議論するのはオープンでイイが、同じくそんな感じに落ち着くんじゃないか？
うまくいけばゴズリンが大好きなemacs lispにまでもっていければってところ。
0158デフォルトの名無しさん
2008/02/16(土) 02:28:000159デフォルトの名無しさん
2008/02/16(土) 02:52:13int 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();
0160デフォルトの名無しさん
2008/02/16(土) 02:53:10全くイメージできないんだけど、どういうこと？
0161デフォルトの名無しさん
2008/02/16(土) 02:58:08可能になるわけじゃないから、匿名内部クラスを普通に使ってる人間には
言語汚染にしか見えんのー。
0162デフォルトの名無しさん
2008/02/16(土) 03:04:54Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahe の４人が
進めている下記のクロージャ仕様(BGGA)ならまともなものだと思うぞ。
http://www.javac.info/closures-v04.html
これがjava7の仕様の一部となることを願うんだ！
0163デフォルトの名無しさん
2008/02/16(土) 03:07:36とかで十分だと思うんだ俺…
0164デフォルトの名無しさん
2008/02/16(土) 05:18:510165デフォルトの名無しさん
2008/02/16(土) 08:45:460166デフォルトの名無しさん
2008/02/16(土) 12:26:060167デフォルトの名無しさん
2008/02/16(土) 12:29:51それは、普通に使われるとセキュリティーに穴が開くからヤバイと思う。
0168デフォルトの名無しさん
2008/02/16(土) 12:48:060169デフォルトの名無しさん
2008/02/16(土) 13:33:31foreachみたいに特定のインタフェースを持ったオブジェクトに適用されるような。
そうなるとJVMがインタフェースを登録するタイミングが気になる。
JEEでClassNotFoundExceptionをやらかす人を増やす仕様だったらどうしよう。
何百個というインタフェースをjava.lang.closureに放り込んで
ブーストラップクラスローダーでロードさせとくとかそういう仕様？
0170デフォルトの名無しさん
2008/02/16(土) 14:47:57全く新しいパラダイムと見るかじゃないか？
全く新しいといいつつも、
{void => void} .equals( new java.lang.Function() {
public void invoke(){}
}
と同じことを仕様として入れたいのだろうけど。（多分）
内部クラスあるけど、GUIだといつも使うし<... onclick="callback()"> のように書ければいいよねだろ。
大元の発想は。
"abc".equals(new String("abc"))
と同程度なことが実現できるメソッド・バージョン。
クロージャを何に活用するかは議論してるみたいだし、知らん。
0171デフォルトの名無しさん
2008/02/16(土) 15:08:49Java 6が出た当初はjsとの連携なんていらんだろと思ってたけど、最近はjsがお気に入り☆
java.nio とか当初はjava.ioあるし、いらんと思ってたけど、これもなかなか。
内部クラスあるし今はクロージャなんて全くいらんとかかも知れんが、クロージャも同じく「なかなか」になるのかと思う。
0172デフォルトの名無しさん
2008/02/16(土) 15:42:560173デフォルトの名無しさん
2008/02/16(土) 15:46:38BGGAもv0.5とかなってるし、間に合わない気が
0174デフォルトの名無しさん
2008/02/16(土) 22:42:220175デフォルトの名無しさん
2008/02/16(土) 22:46:250176デフォルトの名無しさん
2008/02/16(土) 23:07:33|← reject| BGGAの中の人 Closure ユーザー
.￣.||￣￣ ┗(^o^ )┳(｀Д´)┳(^o^ )┛≡＝-
|| ┏┗ ┗┗ ┏┗ ≡＝-
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
0177デフォルトの名無しさん
2008/02/23(土) 00:23:23http://www.java.net/pub/pq/196
こっちの投票だと CICE 3.9%、BGGA 42.7%で 10倍も差がついてる。
javapolisだと、josh blochの公演があったからそれに引きずられたんだろね。
公演前は 2:1 でBGGAの方が投票多かったって書いてあるし。
派閥っても、公演一回でひっくり返るレベルなのよね。
0178デフォルトの名無しさん
2008/02/23(土) 03:01:15正直、CICEは今の匿名クラスに比べて何がメリットかよく分からないので却下したい。
BGGAは、表記がごちゃごちゃして新しい構造が入ってくるので
ぱっと見た目、1.4世代の人が見たらもう分け分からんことになりそうだな、という不安。
まあ、そう言う人は十分Genericsでも分からないコードになってるのかも知れないけど・・・
この表記ならついでに複数返り値もサポートして欲しい感じ。
FCMは、Cとかの関数ポインタに似てるのですっきりしてていいかもしれない。
今のところ一番分かりやすいけどthis#hogehoge()とかしたときに
実行コンテキストが見た目的に予測しにくいな。
ただ、>>106 のARMは欲しい。
こういう分かりやすくなる変更は歓迎したい。
Genericsは訳分からなくなったし。Closureには同じ轍を踏んで欲しくない・・・・
0179デフォルトの名無しさん
2008/02/23(土) 09:10:53ARMってjava.io.Closeableとか、java.util.concurrent.locks.Lockとか
特定のinterface実装してないと使えないみたいだし。
FCMにもJCAあるけど、これはライブラリ側の書き換えが必要になるんかな
0180デフォルトの名無しさん
2008/02/23(土) 23:01:24だからゴチャゴチャして分からなくなるとかはお門違いだと思った。
BGGAとかFCMとか表記やタイプ量が違うだけど、内部では匿名クラスと全く変わんないし。
確かにクロージャは、イベントを超えてラムダみたいに何か活用するなら今までと全く違うから抵抗あるのかもしれない。
必要ないと考えてる奴らはイベント程度でしか見てないし、
イベント以外の活用が見出せないだけじゃないか？
匿名クラスを少し使ってみたら、新しいクラス生成式
（クラス生成リテラル）ってところだなと感じた。
0181デフォルトの名無しさん
2008/02/23(土) 23:02:490182デフォルトの名無しさん
2008/02/23(土) 23:07:22匿名クラスの設計（や表記方法）が中途半端というのはよく分かる。
本心としては、昔は急いでたから匿名・関数生成リテラルまで設計してなかったこと
についての後始末ってとこなんじゃないか？
0183デフォルトの名無しさん
2008/02/23(土) 23:20:190184デフォルトの名無しさん
2008/02/23(土) 23:33:17匿名クラスのシンタックスシュガーレベルの扱いじゃなくて、通常のメソッドがクロージャの簡易構文になってるぐらいでないと意味ない気がする。
0185デフォルトの名無しさん
2008/02/24(日) 00:18:33匿名クラスの設計も表記方法も完成されてると思うよ。
単にタイプ数が多くなるから面倒くさいだけで。
匿名クラスを弄ったCICEが進化だとか、
CICEで匿名クラスは完成された、とか言うなら話は別だけど。
0186デフォルトの名無しさん
2008/02/24(日) 07:18:15クラスである必要のないところにはクロージャを使いたい。
クラス至上主義は要らない。関数は関数だ。
0187デフォルトの名無しさん
2008/02/24(日) 07:21:550188デフォルトの名無しさん
2008/02/24(日) 10:28:49追加せんでもいいと思うんだが。
ジェネリクスやプロパティまでは理解できたが、
クロージャは必要性がよくわからんな。
0189デフォルトの名無しさん
2008/02/24(日) 14:09:450190デフォルトの名無しさん
2008/02/24(日) 14:27:150191デフォルトの名無しさん
2008/02/24(日) 14:33:28禿同。
何でもクラスと言われたSmalltalkより酷いことになってる。
まさにクラス馬鹿一代。> Java
0192デフォルトの名無しさん
2008/02/24(日) 14:44:48苦しいというほど頻繁に使われるシーンが思い浮かばない。
Threadとかもあるし、俺はこの程度なら言語仕様を汚してまで
導入する意義は薄いと思うな。
0193デフォルトの名無しさん
2008/02/24(日) 14:49:350194デフォルトの名無しさん
2008/02/24(日) 15:54:36Future<V>はクラスで適切だと思うけど。
Callable<V>インターフェイスを実装した匿名クラスを書くのが面倒なので
クロージャ使わせろという話と勘違いしていない？
あと、BGGAの block.invoke(args) って記法を block(args) って書けるように
してほしいなぁ。
まあ、RubyのクロージャもWikiPediaによると
># 後に必要になった時点でクロージャを呼び出す。
>@block.call("John")
># 表示:"Hello, John!"
と書いてあって、RubyもJavaのBGGAと同じくあくまでクロージャを
オブジェクト扱いしているっぽい。
なので、Rubyのblock.call(args) みたいに、クロージャの呼び出しは
オブジェクトのメソッド呼び出しと同じように書くのが普通なのかもしれんけど。
0195デフォルトの名無しさん
2008/02/24(日) 16:06:07おれもして欲しい。
けどクロージャができるまでは、メソッドの名前空間と
フィールド/変数の名前空間で分かれてたのに、
closure(arg)を許すと、区別つかなくなるから難しいんじゃね？
0196デフォルトの名無しさん
2008/02/24(日) 16:13:21ぶっちゃけ、プロパティ導入の方が言語仕様が汚れる。
>>195の反対の理屈で、いままでメソッドだったものが
フィールド/変数の名前空間使うことになるから。
0197デフォルトの名無しさん
2008/02/24(日) 16:27:530198デフォルトの名無しさん
2008/02/24(日) 16:33:310199デフォルトの名無しさん
2008/02/24(日) 16:47:13新しい表記、文法の導入はどっちにしても「汚れる」ことに変わりない。
重要なのはそれを許容するだけのメリットがあるかどうか。
0200デフォルトの名無しさん
2008/02/24(日) 16:50:42プロパティは基本的にタイプ数が減るだけ。
0201デフォルトの名無しさん
2008/02/24(日) 16:52:58汚れる程度の問題もあるんだよ。
プロパティ導入は下手するとソース互換性破壊するし。
0202デフォルトの名無しさん
2008/02/24(日) 16:53:530203デフォルトの名無しさん
2008/02/24(日) 16:55:260204デフォルトの名無しさん
2008/02/24(日) 17:07:46バイナリ互換性じゃなくてソース互換性？
「下手すると」って書いてるけど、どの案でどういう問題が？
0205デフォルトの名無しさん
2008/02/24(日) 18:03:08あるクラスにプロパティ hoge と、フィールド hoge があった時に、
識別子 hoge で、フィールドとプロパティどっちアクセスすんの？って話。
プロパティ hoge の宣言と、フィールド hoge の宣言を排他にすりゃ問題ないけど
beans のプロパティ hoge と、フィールド hoge は共存できてたわけで、
安易に排他にするとソース互換性を破壊する。
アクセスレベルのルールをちゃんと考えれば互換性たもてるかもしれんが、
失敗すればフィールドアクセスのつもりがプロパティアクセスになったりしてソース互換性破壊する。
頑張ってアクセス時のルールで互換性維持したとしても
プロパティ hoge を継承クラスのフィールド hoge で隠蔽できるようになったりする。
0206デフォルトの名無しさん
2008/02/24(日) 18:26:02というか、draft3はそういう案じゃなかったか？
で、それが「安易に排他にする」ことだとして、そこで発生する問題は何？
0207デフォルトの名無しさん
2008/02/24(日) 18:30:18標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。
beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。
っつーか、draft3 ってどれの事いってるん？
0208デフォルトの名無しさん
2008/02/24(日) 19:00:33http://docs.google.com/View?docid=dfhbvdfw_1f7mzf2
>標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。
そこであらかじめ定義されたプロパティと同名のフィールドをサブクラスで
定義しなきゃならないケースというのが想像できないんだけど？
もしそれが問題になるんなら、親クラスで定義されるのがプロパティじゃなくて
フィールドでも一緒じゃね？
>beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。
beansと関係ないからこそソース互換性を保てるわけなんだが。
0209デフォルトの名無しさん
2008/02/24(日) 19:48:02自前のクラスで、標準APIのクラス Hoge を継承する SubHoge に、
フィールド hoge が宣言されてるとする。
これは既存のソースでプロパティ導入前にはなんの問題もないけど、
プロパティが導入されて、標準APIのクラス Hoge にプロパティ hoge が後付で導入され、
おまけにプロパティとフィールドが排他だとなると、ソース互換性が破壊されるわけ。
フィールドは隠蔽されるだけだし、最初から存在するルールだからソース互換性は破壊されない。
0210デフォルトの名無しさん
2008/02/24(日) 19:59:01class 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 はコンパイル通らなくなるわな。
0211デフォルトの名無しさん
2008/02/24(日) 20:04:42これができないとどういう場合に困るの？
0212デフォルトの名無しさん
2008/02/24(日) 20:12:09あと、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() を呼ぶべきか？
はたまた同名プロパティは宣言できないようにすべきか？ みたいな問題が出てくる。
まぁ、こーゆーのが現実に問題になるケースは少ないと思うけど
言語仕様上はきっちり決めとかないといけないから。
0213デフォルトの名無しさん
2008/02/24(日) 20:33:45勝手にやっちゃってるフレームワークが氾濫しているのも問題だよな。
0214デフォルトの名無しさん
2008/02/24(日) 20:41:350215デフォルトの名無しさん
2008/02/24(日) 20:44:49でもプロパティってバインド機能があるんだっけか
0216デフォルトの名無しさん
2008/02/24(日) 20:48:480217デフォルトの名無しさん
2008/02/24(日) 21:27:050218デフォルトの名無しさん
2008/02/24(日) 22:29:55int y=new {int a=>a+1}.invoke(20); は分かるが、
int y=new {int a=>a+1}(20); これはどうかと思わないか？
プロパティとかクロージャも含めて、言語仕様にリテラルを入れるのは
直接的には省略した記法でしかない。
やっぱり、それを新規に導入するだけのメリットがあるかどうかだろ。
ジェネリクス同様、所詮はCのマクロの置き換えと同じだしｗ
0219デフォルトの名無しさん
2008/02/24(日) 22:34:53あほかよ
0220デフォルトの名無しさん
2008/02/24(日) 22:44:47やっぱりこれで良いんですけど。
0221デフォルトの名無しさん
2008/02/24(日) 22:45:52bigdecimalのオペレータ[+,*とか]・オーバーロード・サポートもあんまり期待できない。
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があると作った人を疑っちゃうけどね。
0222デフォルトの名無しさん
2008/02/24(日) 22:49:530223デフォルトの名無しさん
2008/02/24(日) 22:53:26匿名クラスとかクロージャとかで関数一つでもクラスをいちいち生成される
とか気にしても、性能に全く関係ないよ。
.classでもメモリ上ではCのように速さとか性能はほぼネイティブと同じになるし、
せいぜいメソッドで動的呼び出しか、静的呼び出しかの違いぐらいじゃないか？
それに、C、jvmくらべるより、それよりもIO待ちのほうがはるかに遅くなるｗ
クラスファイルが多くなるだろうけど、jarで固めるだけだし。
javaとかjvmとかは、C++C＃Rubyみたいにプログラマーよりじゃなくて
実はハードよりの言語（と仕様）だったりする。
確かゴスリン(BGGA)もやる気みたいだったし、あとはjdk1.7に間に合うかどうかだろう。
クロージャは1.7の目玉だしな。
0224デフォルトの名無しさん
2008/02/24(日) 22:56:34それ、何をしたいのかやりたいことは分かるが、そもそもJavaと関係ないだろｗ
0225デフォルトの名無しさん
2008/02/24(日) 23:06:29匿名クラスがjavaのクロージャなんだけど、
そのクロージャってなんだよｗ
0226デフォルトの名無しさん
2008/02/24(日) 23:09:26GUI使わない案件なら、やっぱりJavaはこれでしょ。
クロージャのほうが先に導入されてるとそれなりに面白かったけど。
0227デフォルトの名無しさん
2008/02/24(日) 23:14:33匿名クラスがクロージャそのものなのはC#なんでは？
0228デフォルトの名無しさん
2008/02/24(日) 23:15:46それだけダラダラとタイプ量があるなら匿名クラスと同じ。
ていうか、匿名クラスならまだjavaだけど、それjsだろ。
いつも書いてて絶対に必要になるし、ダラダラ書くの面倒じゃん？ってのが始まりだろう。
0229デフォルトの名無しさん
2008/02/24(日) 23:17:51俺には「C言語はアセンブリのマクロにすぎないから不要」ってぐらい暴論に聞こえるんだが。
クロージャにしたって、一塊の処理の手続きを「ひとつのオブジェクトでもある」のと「データとは異なるものとしてコンパイラに特別扱いしてもらう」のうち後者以外はすべて異端って扱いはどうなのよ。
0230デフォルトの名無しさん
2008/02/24(日) 23:24:33C#のクロージャの話をしたいのか。
0231デフォルトの名無しさん
2008/02/24(日) 23:26:33なかなかの暴論だなｗ
オレには「アセンブリは、所詮はCのベンダー実装に過ぎない」って思ってたけどｗ
0232デフォルトの名無しさん
2008/02/24(日) 23:27:24System.out.println("hello");
});
withLock(lock) {
System.out.println("hello");
}
あたりは本当にいろいろと可能性が広がりそうで楽しみ。
Collectionも引数にクロージャ渡すものがかなり拡張されるだろうね。
0233デフォルトの名無しさん
2008/02/24(日) 23:28:04C#スレでやれよ。
0234デフォルトの名無しさん
2008/02/24(日) 23:30:08何を実現したいのかと、それをどうやるのかの実装とは、別にして考えてみたらどうだ？
それなら全て異端ってことじゃなく、両立可能だろうな。
0235デフォルトの名無しさん
2008/02/24(日) 23:38:09Collectionには手を出さないんじゃないか？
ジネリクスと混じってしまってパッと見なんだか分からなくなる。
ジネリクスは目が慣れるまで少し時間がかかったしｗ
コンカレント辺りのブロッキングキュー・クラスとかでやるならまだしも。
0236デフォルトの名無しさん
2008/02/24(日) 23:40:35C++使いからみれば単純この上ない。
0237デフォルトの名無しさん
2008/02/24(日) 23:54:25それもジェネリクスじゃなくて、C++はテンプレートだろ。
C++のやりたいことは雛形プログラム手法で、Java総称型なんだけど、その様子だと分かってないな。
0238デフォルトの名無しさん
2008/02/24(日) 23:59:23それ、クロージャじゃなくてevalじゃん。
0239デフォルトの名無しさん
2008/02/25(月) 00:02:440240デフォルトの名無しさん
2008/02/25(月) 00:10:35クロージャーであることが目的になっちゃってるの？
0241デフォルトの名無しさん
2008/02/25(月) 00:13:49evalだと静的に色々解析できないじゃん
0242デフォルトの名無しさん
2008/02/25(月) 00:20:020243デフォルトの名無しさん
2008/02/25(月) 00:23:330244デフォルトの名無しさん
2008/02/25(月) 00:24:35少なくともevalを多用するのは嫌い。
evalは(たとえ動的言語であっても)最後の武器だと思ってる。
0245デフォルトの名無しさん
2008/02/25(月) 00:25:110246デフォルトの名無しさん
2008/02/25(月) 00:30:150247デフォルトの名無しさん
2008/02/25(月) 00:39:00C++の方が機能が多いってだけだろ。
C++だってgenericだぜ。
0248デフォルトの名無しさん
2008/02/25(月) 00:39:47馬鹿は頭固いから何言ってもダメだしな。
なぜこんなスレに来ているのかわからんが。
0249デフォルトの名無しさん
2008/02/25(月) 01:02:42JavaのGenericsの機能を本当に使いこなせている？
Google作成のGuiceあたりはGenericsを多用しているので、勉強になる。
これらのソースをすらすら理解でき改造できるようになってから、批判しよう。
0250デフォルトの名無しさん
2008/02/25(月) 01:08:500251デフォルトの名無しさん
2008/02/25(月) 01:21:01@Deprecated じゃないけど 「旧仕様互換ソースはコンパイルできるが新仕様準拠ソースは
コンパイルエラー/ただしランタイムは解決可能」 みたいなアノテーションでも作って。
0252デフォルトの名無しさん
2008/02/25(月) 01:37:260253デフォルトの名無しさん
2008/02/25(月) 04:54:500254デフォルトの名無しさん
2008/02/25(月) 05:55:520255デフォルトの名無しさん
2008/02/25(月) 09:14:430256デフォルトの名無しさん
2008/02/25(月) 14:10:28だれだおまえ？
0257デフォルトの名無しさん
2008/02/25(月) 21:27:340258デフォルトの名無しさん
2008/02/25(月) 21:28:140259デフォルトの名無しさん
2008/02/25(月) 22:15:22ずいぶんと自信過剰ですな。
ところでJVMの実装とかあなたはできるんですか？
0260デフォルトの名無しさん
2008/02/25(月) 23:09:49おまえはだれだ？
0261デフォルトの名無しさん
2008/02/26(火) 00:19:240262デフォルトの名無しさん
2008/02/26(火) 00:28:420263デフォルトの名無しさん
2008/02/26(火) 00:46:08GenericsとJVM実装って全然別やん…
0264デフォルトの名無しさん
2008/02/26(火) 00:55:26マッチポンプで仕事作ってるようも見える。
0265デフォルトの名無しさん
2008/02/26(火) 02:46:250266デフォルトの名無しさん
2008/02/26(火) 02:51:580267デフォルトの名無しさん
2008/02/26(火) 07:47:390268デフォルトの名無しさん
2008/02/26(火) 09:27:530269デフォルトの名無しさん
2008/02/26(火) 09:27:55今更削除できないと思うが。
0270デフォルトの名無しさん
2008/02/26(火) 09:47:040271デフォルトの名無しさん
2008/02/26(火) 10:05:150272デフォルトの名無しさん
2008/02/26(火) 11:57:230273デフォルトの名無しさん
2008/02/26(火) 14:30:54全く何を言いたいのか意味不明なんだが、もっと分かりやすく書き直してくれないか？
0274デフォルトの名無しさん
2008/02/26(火) 20:17:29尖らすの？
0275デフォルトの名無しさん
2008/02/26(火) 23:06:100276デフォルトの名無しさん
2008/02/27(水) 00:32:49boundのダウンキャスト地獄な仕様みた瞬間うんざりしたからいらんけど。
0277デフォルトの名無しさん
2008/02/27(水) 00:44:36アクセッサの表記にget/setがなくなる程度のメリットしかない気がする。
0278デフォルトの名無しさん
2008/02/27(水) 00:53:160279デフォルトの名無しさん
2008/02/27(水) 01:34:49例えばどうやるの？
0280デフォルトの名無しさん
2008/02/27(水) 01:40:24ぐぐってもv4とかなさげなんだけど
0281デフォルトの名無しさん
2008/02/27(水) 01:50:35勝手にやられるより、あったほうが良いんじゃないか？
0282デフォルトの名無しさん
2008/02/27(水) 01:58:51何かアノテーションとコンパイラのサポートで十分な気がするけどこれも言語仕様変える気?
0283デフォルトの名無しさん
2008/02/27(水) 03:34:440284デフォルトの名無しさん
2008/02/27(水) 04:06:280285デフォルトの名無しさん
2008/02/27(水) 05:19:15やっぱ春だな
0286デフォルトの名無しさん
2008/02/27(水) 10:43:09クロージャは入るだろうけど。
>>232のような制御構造に近い記述のメリットが大きいから。
並列とか制御に関するクラスの記述に便利だしね。
0287デフォルトの名無しさん
2008/02/27(水) 10:46:12てか、偶然に速レスになってるし。
0288デフォルトの名無しさん
2008/02/27(水) 14:56:53XMLリテラルとソースファイルのエンコード指定と
RAW文字列？みたいな今不便なところを改善する機能をはやく取り入れてほしい
0289デフォルトの名無しさん
2008/02/27(水) 16:20:49もう入らないと思う。最近続報が全くないので。当時の賛否を考えると、
here documentであることよりもXMLであることがネックになってると思われ
0290デフォルトの名無しさん
2008/02/27(水) 16:54:45+結合だと冗長になる。
0291デフォルトの名無しさん
2008/02/27(水) 21:17:530292デフォルトの名無しさん
2008/02/27(水) 21:21:110293デフォルトの名無しさん
2008/02/28(木) 00:16:520294デフォルトの名無しさん
2008/02/28(木) 06:07:060295デフォルトの名無しさん
2008/02/28(木) 22:47:11契約プログラミングまでいかなくていいので、
派生型としてnull代入を禁止する型がほしい。
0296デフォルトの名無しさん
2008/02/28(木) 22:55:28FindBugs の @NonNull で我慢
0297デフォルトの名無しさん
2008/02/28(木) 22:59:00できれば代入操作時にnullが指定されたら動的に例外投げてくれるような仕組みがあるとうれしいんだけどね。
FindBugsのそれはしらなかったよ。使ってみる。
0298デフォルトの名無しさん
2008/02/29(金) 04:57:360299デフォルトの名無しさん
2008/02/29(金) 05:08:380300デフォルトの名無しさん
2008/02/29(金) 05:21:030301デフォルトの名無しさん
2008/02/29(金) 07:48:050302デフォルトの名無しさん
2008/02/29(金) 22:48:25既存のライブラリを呼ぶときキャストの嵐になるのを覚悟すれば、
null代入可能なものと不可能なものを型システムで区別すること自体は簡単。
Cでいうと、普通のポインタはNULLポインタ型と非NULLポインタ型のunionだと思えばいい。
0303デフォルトの名無しさん
2008/02/29(金) 22:58:23アプローチでする話じゃないのかな。String s not null と思いつきで書いてみると、いずれ
テーブルのカラム宣言のようなカオスになりそうだが。
0304デフォルトの名無しさん
2008/03/01(土) 00:45:54String! s; s = null; // 文法エラー
String t = null; s = t; // 実行時エラー
public void hoge(final String! s){
s.~~(); // 絶対にNullPointerExceptionがおこらない
}
class Hoge<T!>{ }
List<Object!> o = anotherList; // 要素がnullでもとおっちゃうなあ…
0305デフォルトの名無しさん
2008/03/01(土) 00:54:30JCP のケツ追いしかできない連中が集まってるところだから。
0306デフォルトの名無しさん
2008/03/01(土) 01:24:460307デフォルトの名無しさん
2008/03/01(土) 01:45:19JCPになりようもない愚論を大声で喚いている奴より、
JCP追うだけの奴の方がずっとましで有益です。
0308デフォルトの名無しさん
2008/03/01(土) 01:48:340309デフォルトの名無しさん
2008/03/01(土) 02:51:280310デフォルトの名無しさん
2008/03/01(土) 04:37:53また俺様仕様のC＋＋の癖が出でるねｗ
0311デフォルトの名無しさん
2008/03/01(土) 04:52:33どうしてこういう発想になるんだろう？
0312デフォルトの名無しさん
2008/03/01(土) 09:54:18String! s; //<この時点でエラーじゃねーのか？
あと、nullを代入する時点で実行時エラーにするのは、パフォーマンス的にムリ。
setX(X x) { if (x == null) throw NullPointerException("X is not nullable"); this.x = x; }
とかしとけ。
0313デフォルトの名無しさん
2008/03/01(土) 10:30:55nullを代入してはいけないのに、してしまうなんてださいコードだね。
0314デフォルトの名無しさん
2008/03/01(土) 10:32:550315デフォルトの名無しさん
2008/03/01(土) 11:00:36Javaみたいな静的型言語だと、operator overload を使って null 代入チェックしようとすると
クラス単位で null代入可能か不可能かを決めなくちゃいけなくなって逆に不便なような気もするが。
0316デフォルトの名無しさん
2008/03/01(土) 11:31:55Curlとか触ってると、ホントこれはいいアイデアだと思える。
0317デフォルトの名無しさん
2008/03/01(土) 11:34:22そんな糞仕様は勘弁してくれ
0318デフォルトの名無しさん
2008/03/01(土) 11:41:45なんでも静的にやろうとするとリフレクション経由で弄った時に簡単に破綻するような。
0319デフォルトの名無しさん
2008/03/01(土) 11:51:51つ JSR-305
0320デフォルトの名無しさん
2008/03/01(土) 12:06:260321デフォルトの名無しさん
2008/03/01(土) 12:07:400322デフォルトの名無しさん
2008/03/01(土) 12:11:040323デフォルトの名無しさん
2008/03/01(土) 12:33:390324デフォルトの名無しさん
2008/03/01(土) 12:41:26言語にいれろって言っている奴は馬鹿だし。>>304
0325デフォルトの名無しさん
2008/03/01(土) 12:50:120326デフォルトの名無しさん
2008/03/01(土) 13:02:140327デフォルトの名無しさん
2008/03/01(土) 14:03:410328デフォルトの名無しさん
2008/03/01(土) 14:10:19よう、この流れのどこが有益なんだ？
0329デフォルトの名無しさん
2008/03/01(土) 14:21:080330デフォルトの名無しさん
2008/03/01(土) 14:30:450331デフォルトの名無しさん
2008/03/01(土) 14:36:250332デフォルトの名無しさん
2008/03/01(土) 20:42:270333デフォルトの名無しさん
2008/03/02(日) 03:30:15そしてぶちぎれた誰かが、FreeJavaとかNetJavaとか作ればいいと思うお。(*´∀`)
0334デフォルトの名無しさん
2008/03/02(日) 03:36:300335デフォルトの名無しさん
2008/03/02(日) 03:37:450336デフォルトの名無しさん
2008/03/02(日) 06:43:25Java OSとかOpenJavaがないのはネタ？
0337デフォルトの名無しさん
2008/03/02(日) 06:44:57実体はjvm用のバイトコードを生成するコンパイラなんだけど。
だから好きなだけJRubyとかJC++とかJC99とかのコンパイラ作れよｗ
（多分君らのようなMSーC＋＋厨じゃ無理だろうけどｗｗ）
0338デフォルトの名無しさん
2008/03/02(日) 10:37:540339デフォルトの名無しさん
2008/03/02(日) 10:42:33JVMやバイトコードの仕様拡張を含むJCPの議論を知らない知ったか厨だろ。
0340デフォルトの名無しさん
2008/03/02(日) 11:17:14ずっと昔から議論されてるみたいだけど、どの程度すすんでるの？
0341デフォルトの名無しさん
2008/03/02(日) 11:23:42また湧いてきたｗ
もう春かｗｗ
0342デフォルトの名無しさん
2008/03/02(日) 11:43:230343デフォルトの名無しさん
2008/03/02(日) 11:52:590344デフォルトの名無しさん
2008/03/02(日) 12:10:310345デフォルトの名無しさん
2008/03/02(日) 12:15:590346デフォルトの名無しさん
2008/03/02(日) 14:33:290347デフォルトの名無しさん
2008/03/02(日) 15:52:590348デフォルトの名無しさん
2008/03/02(日) 15:53:550349デフォルトの名無しさん
2008/03/02(日) 16:26:350350デフォルトの名無しさん
2008/03/02(日) 16:49:330351デフォルトの名無しさん
2008/03/02(日) 18:53:33はぁ？アホじゃねぇの？
アノテーションはバイトコード内の属性用のブロックに格納されますが？
0352デフォルトの名無しさん
2008/03/02(日) 19:12:060353デフォルトの名無しさん
2008/03/02(日) 19:22:11クラスファイルの仕様は公開されてるんだから調べればわかる
http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf
0354デフォルトの名無しさん
2008/03/02(日) 20:09:570355デフォルトの名無しさん
2008/03/02(日) 21:08:320356デフォルトの名無しさん
2008/03/02(日) 21:59:15何で「あなた」ごときがそれを知ってるんですか？
0357デフォルトの名無しさん
2008/03/02(日) 22:00:490358デフォルトの名無しさん
2008/03/02(日) 22:41:20Not Nullにする構文がどんだけ有益なことかわからんのか。
0359デフォルトの名無しさん
2008/03/02(日) 22:43:26せまい世界の問題に何を必死になってんだか
0360デフォルトの名無しさん
2008/03/02(日) 23:13:240361デフォルトの名無しさん
2008/03/02(日) 23:14:410362デフォルトの名無しさん
2008/03/02(日) 23:50:070363デフォルトの名無しさん
2008/03/03(月) 04:32:200364デフォルトの名無しさん
2008/03/03(月) 04:42:11お上から落ちてきた仕様書の解釈論程度の能力しかない下請け連中が集まってるだけなんだから。
0365デフォルトの名無しさん
2008/03/03(月) 06:41:33というかおまえはJavaa使うな。
おまえはJavaaで何が作れて、Javaaに何期待してるんだ？
吠えてるだけで何も作れない奴はこのあたりで黙っちゃうだがなｗｗｗん？
0366デフォルトの名無しさん
2008/03/03(月) 07:29:46見た目をちょっと変えるだけで何の革新でもないし、
コーディングスタイルの歪な文化をひとつ増やすだけでも迷惑。
0367デフォルトの名無しさん
2008/03/03(月) 07:37:400368デフォルトの名無しさん
2008/03/03(月) 08:14:480369デフォルトの名無しさん
2008/03/03(月) 09:01:120370デフォルトの名無しさん
2008/03/03(月) 09:28:050371デフォルトの名無しさん
2008/03/03(月) 21:16:39そうではない。
進化をとめた言語は、死んだも同然。
C++を見てみろ。
0372デフォルトの名無しさん
2008/03/03(月) 21:18:17むしろ革新多すぎw
0373デフォルトの名無しさん
2008/03/03(月) 21:24:41ありえそうで怖い。
0374デフォルトの名無しさん
2008/03/03(月) 21:29:160375デフォルトの名無しさん
2008/03/03(月) 21:34:490376デフォルトの名無しさん
2008/03/03(月) 21:41:010377デフォルトの名無しさん
2008/03/03(月) 21:43:520378デフォルトの名無しさん
2008/03/03(月) 21:48:452ch で吠えるなよ〜 ｷｬﾝｷｬﾝｗ
0379デフォルトの名無しさん
2008/03/03(月) 22:05:320380デフォルトの名無しさん
2008/03/03(月) 22:06:21GCC拡張で良いんじゃね？
0381デフォルトの名無しさん
2008/03/03(月) 22:08:53花見気分で様子見してろよｗｗｗｗ分かるからｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0382デフォルトの名無しさん
2008/03/03(月) 22:15:39といってもこのスレの住人レベルじゃ無理だろうけどｗ
0383デフォルトの名無しさん
2008/03/03(月) 23:17:290384デフォルトの名無しさん
2008/03/04(火) 00:44:12それなら、ヌルポ出して、その変数に入れるべき値を考察させればいい。
0385デフォルトの名無しさん
2008/03/04(火) 02:36:17Javaは生涯C#に追いつけないことが確定するからな
0386デフォルトの名無しさん
2008/03/04(火) 07:24:02いつになったらVLAを関数に渡せるようになるの
0387デフォルトの名無しさん
2008/03/04(火) 08:10:470388デフォルトの名無しさん
2008/03/04(火) 11:23:390389デフォルトの名無しさん
2008/03/04(火) 11:28:39クロージャは2.0で持ってる
今は3.0ね
0390デフォルトの名無しさん
2008/03/04(火) 11:44:160391デフォルトの名無しさん
2008/03/04(火) 18:40:020392デフォルトの名無しさん
2008/03/04(火) 18:45:280393デフォルトの名無しさん
2008/03/04(火) 18:53:44このスレ関係ないし、まったく興味ないから知らないな。
例えばどれ？
0394デフォルトの名無しさん
2008/03/04(火) 19:04:03関係ないといいつつ話を継続させようとするな
0395デフォルトの名無しさん
2008/03/04(火) 19:14:500396デフォルトの名無しさん
2008/03/04(火) 19:34:36馬鹿かおまいはｗ
0397デフォルトの名無しさん
2008/03/04(火) 19:45:520398デフォルトの名無しさん
2008/03/04(火) 19:53:580399デフォルトの名無しさん
2008/03/04(火) 19:56:38C#は1.0の時から3.0の機能は全部予定してたから今のところ何の破綻もない
一直線だ
むしろ迷走してるのはJavaだな
言語仕様を民主的に決める必要なんてかけらも無いのに
0400デフォルトの名無しさん
2008/03/04(火) 20:02:23ほんと、これからどうして行きたいのかがわからん
0401デフォルトの名無しさん
2008/03/04(火) 21:58:060402デフォルトの名無しさん
2008/03/04(火) 22:01:410403デフォルトの名無しさん
2008/03/04(火) 22:06:36JCPはとどのつまり企業連合な組織だし。
EE6でSpringやS2が壊滅したらちょっと面白い。
0404デフォルトの名無しさん
2008/03/04(火) 22:48:560405デフォルトの名無しさん
2008/03/04(火) 23:05:31jsr166z.forkjoinもかなりいろいろ増えてるし。
Control invocation syntaxが楽しくてたまらん(ﾊｧﾊｧ
0406デフォルトの名無しさん
2008/03/04(火) 23:12:130407デフォルトの名無しさん
2008/03/05(水) 00:27:080408デフォルトの名無しさん
2008/03/05(水) 02:34:54import 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);
}
}
}
0409デフォルトの名無しさん
2008/03/05(水) 10:09:05javaやるとクロージャはどういうのかがやっと理解できるのかもな。
0410デフォルトの名無しさん
2008/03/05(水) 10:11:440411デフォルトの名無しさん
2008/03/05(水) 10:21:06javaの連中もイベント処理でクロージャ（匿名クラス）使ってるって意識はないだろう
イテレータよりは匿名クラス・デリゲートｗのほうがクロージャっぽいけど、まあどっちも同じだ
で、使ってみた感想は将来有望とか利用できるアイディアはいろいろ浮かんでくるか？
0412デフォルトの名無しさん
2008/03/05(水) 17:31:200413デフォルトの名無しさん
2008/03/05(水) 18:35:200414デフォルトの名無しさん
2008/03/05(水) 18:36:24ローカル変数をクロージャが実行される時まで取っておくのが
クロージャの性質だ
0415デフォルトの名無しさん
2008/03/05(水) 18:37:180416デフォルトの名無しさん
2008/03/05(水) 18:53:02new File(path).Read(Input in){
...
}
ブロックを抜けたあと勝手にCloseしてくれるようにできる
0417デフォルトの名無しさん
2008/03/05(水) 19:05:43interface Guess{ int guess(); }
class Fuga{
static Guess hoge(final int i){
return new Guess(){ public int guess(){ return i; } };
}}
個人的にはイテレータとか作るときに使う。
0418デフォルトの名無しさん
2008/03/05(水) 23:38:12サンプル実装では、
・@Sharedアノテーションを付けた変数は、バインディングがヒープに作られ、
スコープ内にあるクロージャで持ち運ぶ事ができる。書き換えても結果が共有される。
(スティール大先生のクロージャ・コメントの通りの仕様
暗黙のヒープ確保はしないのがJava流)
・BGGA v0.5の通り、finalな変数は持ち運べる。
の両方が可能。
v0.6が出て、@Sharedに相当する修飾子が出来るのかどうか、
その辺の議論はまだ追えてません。個人的には、
Java7はv0.5の仕様のままで、Java8まで持ち越した方がいいような気がします。
先に解決すべき「Open Issues」があるように思うので。
Doug Lea大先生のjsr166y fork-join frameworkがこなれてきてから、
並列実行での"shared"も同時に解決するようなスキームが望ましいと思うので。
0419デフォルトの名無しさん
2008/03/05(水) 23:41:19> Control invocation syntaxが楽しくてたまらん(ﾊｧﾊｧ
構造化プログラミングでいうところの構造的な制御構造は何でも作れますね。
ifとかwhileとか。
継続とtail jumpがないから非構造的な制御構造は無理だけど。
ただサンプル実装では、>>405の通り、
returnでクロージャの外の関数を出られる実装が出てきそうだけど。
0420デフォルトの名無しさん
2008/03/05(水) 23:50:110421デフォルトの名無しさん
2008/03/05(水) 23:53:00普通の変数を突っ込まなきゃならないケースが思いつかないし
ややこしくて危険でもある気がする
0422デフォルトの名無しさん
2008/03/05(水) 23:54:180423デフォルトの名無しさん
2008/03/05(水) 23:57:14リターンバッファのようにあからさまに意図したものならともかく。
0424デフォルトの名無しさん
2008/03/05(水) 23:58:33こんなんじゃXML hellがAnnotation hellに置き換わるだけだ。
0425デフォルトの名無しさん
2008/03/06(木) 00:13:42アノテーションは、プログラムに付ける付箋紙のような役割から
ロジックと複雑に絡み合ったカオスの元になりつつあるな。
プログラム的な定義は、言語として定義してくれ。
@Shared アノテーションは、アノテーションの誤用としか思えない。
0426デフォルトの名無しさん
2008/03/06(木) 00:24:43処理系独自の意味を与えられる(Cの#pragmaのように)
アノテーションを使っているだけだと思います。
もし必要だということになれば、修飾子になるのでしょう。
Doug Lee大先生が今この辺りのことをどうしているかは追えてないです。
ただ並列に動いているクロージャ同士が、
「環境」を共有しているって状況はとても自然で、応用によっては有益なので、
full closureはいつか入るだろうし、また入るべきだと思います。
0427デフォルトの名無しさん
2008/03/06(木) 00:26:23サンプル実装と仕様提案を混同して議論しないようにしましょう。
>>418に書いたのはサンプル実装のことで、
@Sharedを使うなんて提案は全くありません。
0428デフォルトの名無しさん
2008/03/06(木) 00:27:130429デフォルトの名無しさん
2008/03/06(木) 00:31:410430デフォルトの名無しさん
2008/03/06(木) 00:35:450431デフォルトの名無しさん
2008/03/06(木) 00:39:37MobileAgent系の話のように見えるけど、なんでOS仮想化技術が出てくるんだろう・・・？
Voteのコメントが、何か学生の研究に対するコメントのようで笑えてしまった。
0432デフォルトの名無しさん
2008/03/06(木) 00:39:54for(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ないけど
0433デフォルトの名無しさん
2008/03/06(木) 00:53:290434デフォルトの名無しさん
2008/03/06(木) 00:58:50あそこで言っている仮想化は、
OSに対して行う仮想化じゃなくて、
OSがリソースに対して行う仮想化。
例えば、JavaにIPアドレスをmobile可能にする細工を入れるんじゃなくて、
Mobile IP使えば解決する、まあそんな話。
幾らなんでも早急だったと思うし。研究としては悪くないけど。
0435デフォルトの名無しさん
2008/03/06(木) 09:44:35今なら出来そうだというところが大きいんじゃないか。
次は見た目関数型らしきのも入れて、そんなJavaはsmalltalkとかを中心とした昔の技術の集大成でしかないしｗ
0436デフォルトの名無しさん
2008/03/06(木) 09:47:150437デフォルトの名無しさん
2008/03/06(木) 10:02:45ここは最新追っかけだし、せっかくならJava話をしてC＃の話もついでに披露してくれないか
たとえば、おまえの頭にはMacやLinuxにはすごいハッカーがたくさんいるとか考えた事もないだろ？
0438デフォルトの名無しさん
2008/03/06(木) 10:07:22何いってんのかわかんねえけど俺はクロージャにはfinalなローカル変数が入れられれば
十分だと思っていて、C#ではfinal以外が入れられることでどういう不都合が起こるかを述べている
0439デフォルトの名無しさん
2008/03/06(木) 10:14:16>>432って不都合か？ せいぜい「評価されるタイミングが俺の好みじゃない」っつーだけのような。
初心者が使いやすい、あんな記述やこんな記述でトラブルの元になってるとか、
そこらへんまで言わないとfinal以外が入れられると不都合、って話にはならんような。
0440デフォルトの名無しさん
2008/03/06(木) 10:14:19お前痛いよ
0441デフォルトの名無しさん
2008/03/06(木) 11:37:23C#の話はいいです。
0442デフォルトの名無しさん
2008/03/06(木) 12:05:48C#の話じゃないって。
unrestricted closure には、取り囲むスコープの変数なら final も @Shared もなしで取り込める。
0443デフォルトの名無しさん
2008/03/06(木) 12:38:300444デフォルトの名無しさん
2008/03/06(木) 13:17:41少し花見でもしてたつもりですけど、それなら徹底的に排除するまでですけど？
0445デフォルトの名無しさん
2008/03/06(木) 13:25:25linux, macの奴らはC#など触ったこともないだろ。
奴らの話を聞くだけで耳が腐るｗ
所詮C＃はドカタ候補専用だしな
0446デフォルトの名無しさん
2008/03/06(木) 13:34:480447デフォルトの名無しさん
2008/03/06(木) 13:36:54仮に 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が入りそうにないって話も信憑性無いし。
0448デフォルトの名無しさん
2008/03/06(木) 13:38:43いつの時代もMSの奴らはキモイってことだな
0449デフォルトの名無しさん
2008/03/06(木) 13:56:44javac.infoの実装だと、
unrestrictedは==>で区別することになってますね。
=>はjava.lang.RestrictedFunctionなクロージャ。
0450デフォルトの名無しさん
2008/03/06(木) 14:03:34それは知ってる。
けど unrestricted 入れないつもりなら unrestricted と restricted の区別なんか必要ないんだから
java.lang.RestrictedFunction 自体要らないでしょ。
0451449
2008/03/06(木) 14:04:300452デフォルトの名無しさん
2008/03/06(木) 14:20:49おれにはJava最新追っかけスレでC#のことをウダウダ言う奴の方がどう見ても痛い
たぶんおまえの方が痛いｗ
0453デフォルトの名無しさん
2008/03/06(木) 14:22:520454デフォルトの名無しさん
2008/03/06(木) 14:37:560455デフォルトの名無しさん
2008/03/06(木) 14:38:23> 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のプロトタイプに導入されてるね。
0456デフォルトの名無しさん
2008/03/06(木) 14:57:510457デフォルトの名無しさん
2008/03/06(木) 15:03:45{ => method(); } と { => method() } と、ぱっと見て区別つかん。
0458デフォルトの名無しさん
2008/03/06(木) 15:22:52@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);
0459デフォルトの名無しさん
2008/03/06(木) 15:41:22今日落としたプロトタイプ実装だと、
@Sharedつけなくても警告がでるだけでコンパイルエラーにならんような
これ、ホームページには updated 2008-02-22 って書いてあるけど、
解凍すると closures-2008-03-05ってディレクトリができる……
コッソリと何か変わってたりするんだろうか？
0460デフォルトの名無しさん
2008/03/06(木) 16:36:452008-02-26ってのもあるし。
0461デフォルトの名無しさん
2008/03/06(木) 19:22:17警告は出るけどコンパイルエラーにはならなかった。
0462デフォルトの名無しさん
2008/03/06(木) 19:37:460463デフォルトの名無しさん
2008/03/06(木) 20:12:41このスレじゃまともな技術的議論はできそうにないな
0464デフォルトの名無しさん
2008/03/06(木) 20:27:43JCP = バチカン、JSR = 教典、それ以外の論議 = 異端 = 叩き、な
ご熱心な殉教者しか居ないのは昔からの事。あ、こりゃ保守というか権威主義か。
0465デフォルトの名無しさん
2008/03/06(木) 21:12:550466デフォルトの名無しさん
2008/03/06(木) 21:14:480467デフォルトの名無しさん
2008/03/06(木) 21:26:1710,10,10...？0,1,2,3,4...？
0468デフォルトの名無しさん
2008/03/06(木) 23:18:14バチカンとか経典とか、お前頭は相当おかしくなっちまってるようだなｗ
0469デフォルトの名無しさん
2008/03/06(木) 23:20:000470デフォルトの名無しさん
2008/03/06(木) 23:32:55技術的な議論とかしたいなら、せめてJavaスレにふさわしくJavaでやれよ。
C＃スレでPHPとかVBとかで議論wとか通用しないのと同じだろ。
これに気がつかないおまえのバカさ加減にあきれるw
0471デフォルトの名無しさん
2008/03/06(木) 23:33:08それスタックの状態を保存するという考えに基づけば正常な動作じゃないか？
0472デフォルトの名無しさん
2008/03/06(木) 23:35:33もうおまえはこのスレに来なくていいよ。おまえみたいな奴が一人でもいると、スレが荒れるだけだから。
0473デフォルトの名無しさん
2008/03/06(木) 23:37:22バチカンとか意味不明な奴もお花畑板いけよw
0474デフォルトの名無しさん
2008/03/06(木) 23:39:11どうしてくれるんだ？おい、おまえら！！
>>463-464
おまえら責任とれよな
0475デフォルトの名無しさん
2008/03/06(木) 23:40:120476デフォルトの名無しさん
2008/03/06(木) 23:41:220477デフォルトの名無しさん
2008/03/06(木) 23:48:20こういうことは言うのは派遣かニートだろ。
こんな社会のカスは相手にすんなよ。
違うスレでは「ニート達よ団結せよ！」とかいってる奴だからw
0478デフォルトの名無しさん
2008/03/06(木) 23:51:25偽・スルー みんなにスルーを呼びかける。実はスルーできてない。 ← >>477
予告スルー レスしないと予告してからスルーする。
完全スルー スレに参加すること自体を放棄する。
無理スルー 元の話題がないのに必死でスルーを推奨する。滑稽。
失敗スルー 我慢できずにレスしてしまう。後から「暇だから遊んでやった」などと負け惜しみ。
願いスルー 失敗したレスに対してスルーをお願いする。ある意味３匹目。
激突スルー 話題自体がスルーの話に移行してまう。泥沼状態。
疎開スルー 本スレではスルーできたが、他スレでその話題を出してしまう。見つかると滑稽。
乞食スルー 情報だけもらって雑談はスルーする。
質問スルー 質問をスルーして雑談を続ける。
思い出スルー 攻撃中はスルーして、後日その思い出を語る。
真・自演スルー 議論に負けそうな時、ファビョった後に自演でスルーを呼びかける。
偽・自演スルー 誰も釣られないので、願いスルーのふりをする。狙うは４匹目。
３匹目のスルー 直接的にはスルーしてるが、反応した人に反応してしまう。
４匹目のスルー ３匹目に反応する。以降５匹６匹と続き、激突スルーへ。
0479デフォルトの名無しさん
2008/03/06(木) 23:51:43明日も分からない全然決まってもないことだろ
久々にすれ盛り上がってるけど、他にネタないのか
結局は海外のソースに依存することになるんだろうけど、jdk1.8ねたとか、
いまホットなライブラリネタとかないの？
0480デフォルトの名無しさん
2008/03/07(金) 00:00:27何この必死君
0481デフォルトの名無しさん
2008/03/07(金) 00:02:00これ初だけど、いつのコピペ？
というかスルー以前（あおりとかあらし以前）に
次世代JavaスレなのにC＃とかC＋＋とかスレ違いじゃないかのか？
C＃とかC＋＋で出来てるだろ、だからJavaでもやれよって論法が多いが、こいつらサルだろｗ
0482デフォルトの名無しさん
2008/03/07(金) 00:03:09ホットなライブラリ(笑)
0483デフォルトの名無しさん
2008/03/07(金) 00:03:40いや、バチカンとかぬかす奴よりは、やつの言い分の方が正しい
0484デフォルトの名無しさん
2008/03/07(金) 00:05:15おまえ、いつも同じこといってるだろ
0485デフォルトの名無しさん
2008/03/07(金) 00:08:32たまに自分が判定する側の人間になってると勘違いしてる人もいるようですけど。
0486デフォルトの名無しさん
2008/03/07(金) 00:13:31このスレ初めて見ただけど、確かにそいつはゴミみたいなやつだな。
というか、そばに同じようなキモイ奴がいるんだよな。
こいつ、何とかしてやってくれよ。
0487デフォルトの名無しさん
2008/03/07(金) 00:18:09> このスレ初めて見ただけど
わざわざ自爆宣言するの流行ってるの？
0488デフォルトの名無しさん
2008/03/07(金) 00:27:52スルー出来んのか？おまえもカスだしなｗ
0489デフォルトの名無しさん
2008/03/07(金) 00:33:05いちいち食って掛かるバカが多すぎる。
0490デフォルトの名無しさん
2008/03/07(金) 00:33:34知能のある方は以下正常化でよろすく。
0491デフォルトの名無しさん
2008/03/07(金) 00:36:25ニートはもともと社会のカスだし別にどうでもいいからｗｗｗｗｗ
0492デフォルトの名無しさん
2008/03/07(金) 00:40:260493デフォルトの名無しさん
2008/03/07(金) 00:42:51＞見せれるとな。
みせれる？
0494デフォルトの名無しさん
2008/03/07(金) 00:47:21ワロタｗｗ
0495デフォルトの名無しさん
2008/03/07(金) 00:54:49それからscalaとかgooglebyとか勧めてる奴もいるけど、今ならrubyだろうな。
rubyなんて正にモルモンしてるけど、perlほどキチガイじゃない。（上にあったのはバチカンだったか？）
0496デフォルトの名無しさん
2008/03/07(金) 00:57:280497デフォルトの名無しさん
2008/03/07(金) 00:59:550498デフォルトの名無しさん
2008/03/07(金) 01:00:270499デフォルトの名無しさん
2008/03/07(金) 01:01:52多分ネタだろうけど、一瞬googleboyに見えたｗｗｗ
0500デフォルトの名無しさん
2008/03/07(金) 01:05:30Javaにも最前線にも失礼。
全人類的にこのスレッドは汚物、失礼なものにあたる。
0501デフォルトの名無しさん
2008/03/07(金) 01:09:05英語は出来ないけどなｗ
0502デフォルトの名無しさん
2008/03/07(金) 01:15:28早く寝ろよ。派遣先は遠いから明日も早く起きなければいけないんだろ？
0503デフォルトの名無しさん
2008/03/07(金) 01:17:42全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
0504デフォルトの名無しさん
2008/03/07(金) 01:18:540505デフォルトの名無しさん
2008/03/07(金) 01:19:20おまえは、カマキリでも食っちまったんじゃないか？
0506デフォルトの名無しさん
2008/03/07(金) 01:23:43jdk7の次のビルドでも出てくれば少しは矛先が変わるのになぁ。
12月からビルド止まったままだし・・・
0507デフォルトの名無しさん
2008/03/07(金) 01:28:23一緒に死ねよ。もうおまえの負けだな。
はよオナニーして寝ろｗ
0508デフォルトの名無しさん
2008/03/07(金) 01:29:220509デフォルトの名無しさん
2008/03/07(金) 01:30:080510デフォルトの名無しさん
2008/03/07(金) 01:36:200511デフォルトの名無しさん
2008/03/07(金) 01:37:44はよオナニーして寝ろYO
0512デフォルトの名無しさん
2008/03/07(金) 01:44:170513デフォルトの名無しさん
2008/03/07(金) 01:57:05誰だおまえ？
0514デフォルトの名無しさん
2008/03/07(金) 02:01:03これが噂の負け組みの人だから、かまっちゃダメ！！
0515デフォルトの名無しさん
2008/03/07(金) 02:03:030516デフォルトの名無しさん
2008/03/07(金) 02:30:300517デフォルトの名無しさん
2008/03/07(金) 02:31:370518デフォルトの名無しさん
2008/03/07(金) 02:37:45ゴズリンさんいますか？
0519デフォルトの名無しさん
2008/03/07(金) 03:27:18冶金お疲れ様っす！！
0520デフォルトの名無しさん
2008/03/07(金) 08:09:52Scalaは中の人の議論でもよく出てくる言語だよ。
やっぱりよく出来てる。使ってねーけどw
0521デフォルトの名無しさん
2008/03/07(金) 08:16:560522デフォルトの名無しさん
2008/03/07(金) 15:55:38使えば分かるよ。Javaから見れば何でもありだからｗ
0523デフォルトの名無しさん
2008/03/07(金) 19:51:100524デフォルトの名無しさん
2008/03/07(金) 22:44:280525デフォルトの名無しさん
2008/03/07(金) 22:52:210526デフォルトの名無しさん
2008/03/08(土) 00:19:400527デフォルトの名無しさん
2008/03/08(土) 01:09:17ニート乙
0528デフォルトの名無しさん
2008/03/08(土) 01:10:460529デフォルトの名無しさん
2008/03/08(土) 11:59:230530デフォルトの名無しさん
2008/03/08(土) 12:51:330531デフォルトの名無しさん
2008/03/08(土) 13:15:380532デフォルトの名無しさん
2008/03/08(土) 17:01:22ニートなんですが…ボクちんもいいですか（・＝・）
0533デフォルトの名無しさん
2008/03/08(土) 22:44:17誰だってJava使っていいですよね？
0534デフォルトの名無しさん
2008/03/09(日) 11:44:37何でもできるとかそんなことじゃなくて、すごく良く設計されている。
0535デフォルトの名無しさん
2008/03/09(日) 15:38:37ボクちんニートなんですが…
0536デフォルトの名無しさん
2008/03/09(日) 22:07:150537デフォルトの名無しさん
2008/03/09(日) 22:25:370538デフォルトの名無しさん
2008/03/10(月) 01:34:42> 激突スルー
0539デフォルトの名無しさん
2008/03/11(火) 11:37:58Closures for Java
http://jazoon.com/download/presentations/1680.pdf
0540デフォルトの名無しさん
2008/03/11(火) 19:49:32for each (String name, Thing thing : myMap) {
if (thing.isCocksucker()) {
return; // ← ｺｲｼはどこに return するのかね？
}
doSomething(name, thing);
}
0541デフォルトの名無しさん
2008/03/11(火) 19:57:150542デフォルトの名無しさん
2008/03/11(火) 20:24:55>>540
>>540
>>540
0543デフォルトの名無しさん
2008/03/11(火) 20:45:25java.awt.event.ActionListener とかみたいに、メソッド一個の場合は良いけど
java.awt.event.MouseListener とかみたいに幾つもメソッドある場合とか。
MouseAdapter 使っても名前指定できないとアレだし。CICE も同じ問題かかえてる。
FCM だと Named inner method が作れるから、この点は問題にならんのだけど。
やっぱ BGGA だと
public void onMouseClicked({MouseEvent e => void} block) {
addMouseListener(new MouseAdaptor(){
public void mouseClicked(MouseEvent e){ block.invoke(e); }
});
}
みたいな感じにすんのかなぁ？ メソッド数が大変な事になるような気もするけど。
0544デフォルトの名無しさん
2008/03/11(火) 20:57:590545デフォルトの名無しさん
2008/03/11(火) 21:32:42クロージャと、関数オブジェクトとか関数リテラルみたいなラムダとの違いって？
0546デフォルトの名無しさん
2008/03/11(火) 22:20:39void addMouseActions(java.awt.Component foo,
{MouseEvent e => void} clicked,
{MouseEvent e => void} released,
{MouseEvent e => void} entered) {
foo.addMouseListener(new MouseListenerBuilder()
.setMouseClicked(clicked) // null check wished?
.setMouseReleased(released)
.setMouseEntered(entered);
}
0547デフォルトの名無しさん
2008/03/11(火) 23:16:07それだと順番間違えやすいし、順番間違えてもコンパイル時にチェックできないから
実行時に変な動作してから初めて気付く事になるような……
0548デフォルトの名無しさん
2008/03/12(水) 01:37:02変な人。
0549デフォルトの名無しさん
2008/03/12(水) 08:09:040550デフォルトの名無しさん
2008/03/12(水) 09:22:49実際比べてみると匿名クラス使う場合とタイプ数もあんまり変わらんのよね。
builderパターン + クロージャ：
addMouseListener(new MouseListenerBuilder().setMouseClicked({MouseEvent e => System.out.println("clicked"); }));
adapter + 匿名クラス：
addMouseListener(new MouseAdapter(){ public void mouseClicked(MouseEvent e){ System.out.println("clicked"); } });
0551デフォルトの名無しさん
2008/03/12(水) 12:03:38({arg => hogehoge})(arg);
0552デフォルトの名無しさん
2008/03/12(水) 12:06:590553デフォルトの名無しさん
2008/03/12(水) 12:34:23BGGA v0.5にはない。
0554デフォルトの名無しさん
2008/03/12(水) 12:34:44下位互換考えるともう変更できんだろ・・
0555デフォルトの名無しさん
2008/03/12(水) 12:37:22それだと単なるキャストだね。
argがクラス名と変数名/フィールド名で重複してるけど。
0556デフォルトの名無しさん
2008/03/12(水) 12:39:02openjdkあたりにパッチ送れば？ acceptされるとは限らんけど。
0557デフォルトの名無しさん
2008/03/12(水) 12:43:30将来採用されることもありうる。
0558デフォルトの名無しさん
2008/03/12(水) 13:50:47タイプ量が多いとかはエイリアスで解決できるわけで、クロージャの言語仕様とは全く関係ない。
といいつつもJavaではtypedefみたいのは永遠とサポートされないと思うけど。
0559デフォルトの名無しさん
2008/03/12(水) 14:21:240560デフォルトの名無しさん
2008/03/12(水) 15:14:220561デフォルトの名無しさん
2008/03/12(水) 16:00:16ヘッダファイルを使うC言語と違って、
Javaのコンパイル単位はtypedefと相性悪いでしょ。
publicクラス毎に、何回も同じtypedefを書く必要出てくるし。
あと、typedef入れるより型推論が入った方が嬉しいぞ。
0562デフォルトの名無しさん
2008/03/12(水) 17:09:38型推論と似てるけど、型推論は動的にやるでしょｗ
もしあるなら、typedefは静的におこなわれる、型(class)別名で、
変数のようにスコープを持つとかなら、
CやC++ templeteのようにバグとか追跡不可能で
エラーメッセージも意味不明にまでなったりしないと思う。
だから、やっぱり長いしタイプ量が変わんないじゃんというのは分かるけど、
タイプ量が多いのとクロージャとは関係ない。
0563デフォルトの名無しさん
2008/03/12(水) 17:13:03結局はtypedefやりたいならアノテーションつかってツール作って自分でやってくれよってなるんじゃないか。
0564デフォルトの名無しさん
2008/03/12(水) 17:16:420565デフォルトの名無しさん
2008/03/12(水) 17:56:300566デフォルトの名無しさん
2008/03/12(水) 18:25:48タイプ量が多いのとクロージャは関係ないよ。
タイプ量が多いと builderパターン+クロージャで
リスナを生成するのが面倒くさいってだけで。
それに別名定義できても、C言語のヘッダファイルみたいなものがないと
それほど便利にはならないっしょ。それよりは型推論の方がいいって事。
型推論も別名定義も両方あってもいいけどさ。
0567デフォルトの名無しさん
2008/03/12(水) 18:35:57もっとも、これは generics でバカみたいに長くなった型名を短くてわかりやすいものにするのが
主な目的っぽいから、>>550 みたいに generics使ってない上に、
MouseListenerBuilder やら setMouseClickled やら MouseEvent やらの
個々の識別子は長すぎて読み易さを低下させてる、ってわけでもないのに
使うようなモンでもねーと思うが。
0568デフォルトの名無しさん
2008/03/12(水) 18:47:240569デフォルトの名無しさん
2008/03/12(水) 19:22:09>>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"); }));
0570デフォルトの名無しさん
2008/03/12(水) 19:24:45なにこれ
0571デフォルトの名無しさん
2008/03/12(水) 19:30:27よーするに、可読性落とさないような名前が思いつかないなら
>>550のタイプ量は妥当だって事。
0572デフォルトの名無しさん
2008/03/12(水) 21:31:24onMouseClicked({MouseEvent e => System.out.println("clicked"); });
で良いんだし。もしくは >>543 と control invocation syntax 使って
onMouseClicked(MouseEvent e){ System.out.println("clicked"); }
0573デフォルトの名無しさん
2008/03/12(水) 21:42:20下らないミスが減ったりするわけじゃないんでしょ。拡張 for 並みに
どうでもいいんだけど。
0574デフォルトの名無しさん
2008/03/12(水) 21:43:13エイリアスやらマクロやらプリプロセッサやら出してくるぐらいなら、そっちのがいいね
0575デフォルトの名無しさん
2008/03/12(水) 22:01:29いちいちインデクサなんて書いてられるか可読性も落ちる。
0576デフォルトの名無しさん
2008/03/12(水) 22:04:290577デフォルトの名無しさん
2008/03/12(水) 22:10:250578デフォルトの名無しさん
2008/03/12(水) 23:00:420579デフォルトの名無しさん
2008/03/12(水) 23:01:12C#に洗脳されすぎｗ
0580デフォルトの名無しさん
2008/03/12(水) 23:03:18それぐらい頭使え。
0581デフォルトの名無しさん
2008/03/12(水) 23:12:34で、短いメソッド名で実装して、それを呼び出すことね。
0582デフォルトの名無しさん
2008/03/12(水) 23:26:280583デフォルトの名無しさん
2008/03/12(水) 23:30:000584デフォルトの名無しさん
2008/03/12(水) 23:31:020585デフォルトの名無しさん
2008/03/13(木) 00:02:39お前は日本語でプログラム書くのか？
0586デフォルトの名無しさん
2008/03/13(木) 00:16:46Javaでもインデクサって普通に呼ぶだろうね。
Javaもinterface経由で演算子オーバーロードに対応したらいいのに。
AppendableとかCalculateableみたく、目的を明示すれば設計者も馬鹿しないでしょ。
0587デフォルトの名無しさん
2008/03/13(木) 00:21:010588デフォルトの名無しさん
2008/03/13(木) 00:28:40いやいや、言いたいのは話をわざわざ分かりにくくするために英語にする必要はないだろうということ。
0589デフォルトの名無しさん
2008/03/13(木) 00:33:240590デフォルトの名無しさん
2008/03/13(木) 02:05:45ループ抽象(拡張for)
コントロール・インヴォケイション・シンタックス
は過激に便利ですよ。>>539のp4-6見てください。
プログラム構造がかなりすっきりまとまります。
プログラム内でのコードの共通化も進みますし。
0591デフォルトの名無しさん
2008/03/13(木) 03:43:590592デフォルトの名無しさん
2008/03/13(木) 06:40:120593デフォルトの名無しさん
2008/03/13(木) 14:00:38おまえも
0594デフォルトの名無しさん
2008/03/13(木) 21:56:17別に相性は悪く無いと思う
以下のような感じで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) {
....
}
}
0595デフォルトの名無しさん
2008/03/13(木) 22:49:58それをやるには static import とは別の仕組みが必要になるし、
どうせやるなら class Alias みたいなものをヘッダファイルモドキとして使うのは間抜けすぎる。
0596デフォルトの名無しさん
2008/03/13(木) 23:59:35それ言っちゃおしまいでしょ。
java.lang.Math とか java.util.Collections とか、
クラス外にメソッド置いとけるんならクラス外に置きたいようなのは標準APIにも多いし。
Java でやるなら >>594 みたいなやり方しかないと思うけどね。
0597デフォルトの名無しさん
2008/03/14(金) 00:01:58> 型推論と似てるけど、型推論は動的にやるでしょｗ
MLなどの型推論はコンパイル時に静的にやるよ。
動的だったら、型を推論するまでもなくチェックすればいい。
>>567が言っているような、
generics使って汎用に書かれたクラスに、
具体的なクラスを与えて、新たなクラスとしてpublicにする、
って機能は必須だと思う。
ただconcept(C++), type class(haskell)のような形の方が
より汎用でスマートだと思う。単なるエイリアスじゃなくて
両クラスのグルーとなるコードも加えられるし。
0598デフォルトの名無しさん
2008/03/14(金) 00:05:28クラス外メソッド定義とクラスエイリアスは別件。
0599デフォルトの名無しさん
2008/03/14(金) 00:15:29クラス外メソッド定義したいって言ってるんじゃなくて
言語仕様が許すなら必ずしもクラス内に置く必要ないエイリアスやメソッドを
クラス内に置かなきゃいけないのは等しくアレだって事
0600デフォルトの名無しさん
2008/03/14(金) 02:39:520601デフォルトの名無しさん
2008/03/14(金) 03:01:16もっと AOP 的設計が出来るようなアプローチしろよ。インスタンスフィールドへの
アクセスもトラップできるようにすればそもそもプロパティ拡張もいらんだろが。
0602デフォルトの名無しさん
2008/03/14(金) 03:44:370603デフォルトの名無しさん
2008/03/14(金) 05:49:16フィールドアクセスがめちゃくちゃ遅くなりそうだな
0604デフォルトの名無しさん
2008/03/14(金) 06:29:16まぁプロパティアクセスに関しては「後で」「静的に」「他のソースを修正せずに」アクセサを
追加できれば十分だが。
0605デフォルトの名無しさん
2008/03/14(金) 06:51:540606デフォルトの名無しさん
2008/03/14(金) 06:54:170607デフォルトの名無しさん
2008/03/14(金) 07:11:520608デフォルトの名無しさん
2008/03/14(金) 07:28:450609デフォルトの名無しさん
2008/03/14(金) 07:33:040610デフォルトの名無しさん
2008/03/14(金) 07:58:330611デフォルトの名無しさん
2008/03/14(金) 10:58:17そか？ 隠蔽されたフィールドに対するアクセスとかも考えたら
プロパティモドキじゃ対応できないし馬鹿みたいにでかい仕組みが必要になると思うが。
0612デフォルトの名無しさん
2008/03/14(金) 12:18:310613デフォルトの名無しさん
2008/03/14(金) 12:22:350614デフォルトの名無しさん
2008/03/14(金) 12:30:48それだけなら何とかなると思うが……
もっとも、リフレクション対応までして「インスタンスフィールドアクセスのトラップ」
できるようにするより他の事にエネルギー使って欲しいぞ。
0615デフォルトの名無しさん
2008/03/14(金) 15:49:59S ｾｯｸﾙして
0616デフォルトの名無しさん
2008/03/14(金) 16:03:51現時点でも少なくともリフレクション程度は確保できる。
まぁフィールドアクセスはそれも包含できるという意味で引き合いに出しただけで本意は別。
ゴリゴリ書くしかなかったのを簡素化したいのはもっともだが、なら無名内部クラスより
DI の標準様式一つでも考慮しろと。
0617デフォルトの名無しさん
2008/03/14(金) 16:14:40？
0618デフォルトの名無しさん
2008/03/15(土) 01:41:010619デフォルトの名無しさん
2008/03/15(土) 10:17:10つーか選択肢は二つくらい(?)あって
・クロージャから抜けるのみ ・・ >>540のコードなら、doSomething() が実行されないだけで for each は続く
・for each の置かれているメソッドから抜ける
「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら
前者が選ばれるだろうなと思ってさ。
0620デフォルトの名無しさん
2008/03/15(土) 10:19:34> 「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら
違う。
0621デフォルトの名無しさん
2008/03/15(土) 10:32:190622デフォルトの名無しさん
2008/03/15(土) 11:45:56ECMAScript風になるのか、ruby風になるのか。
0623デフォルトの名無しさん
2008/03/15(土) 11:54:42statements が書けるクロージャの2種類作るってのもアリだと思うんだけど。
0624デフォルトの名無しさん
2008/03/15(土) 11:54:490625デフォルトの名無しさん
2008/03/15(土) 12:41:25何がどこに抜けるんだかバージョンによって変わるだなんて
0626デフォルトの名無しさん
2008/03/15(土) 13:29:50クロージャやブロックではない。
詳しくは http://www.javac.info/closures-v05.html を読め。
0627デフォルトの名無しさん
2008/03/31(月) 04:07:09なんでこんな設計にしたんだ
0628デフォルトの名無しさん
2008/03/31(月) 04:15:550629デフォルトの名無しさん
2008/04/01(火) 08:58:11てか他に手は無いだろ
0630デフォルトの名無しさん
2008/04/02(水) 02:03:03相性が悪いって程でもないと思うが
確かBGGAでは、function typeをListenerに暗黙に変換するための
仕掛けが用意されるんじゃなかったっけか
0631デフォルトの名無しさん
2008/04/02(水) 09:54:37ActionListenerみたいにメソッド一個しか無い場合は変換できるけど、
BGGAには、MouseListenerみたいにメソッドいっぱいある場合の変換の仕掛けはないよ。
named inner methodがあるFCM と比べると、BGGAとXxxListenerは相性悪い。
0632デフォルトの名無しさん
2008/04/02(水) 10:02:50method reference だそーです。
method reference に '#' 使うのが平気な感覚もってるのに
accessing property に '.' 以外の演算子使うのってダメなんかねぇ…… と思ったり。
0633デフォルトの名無しさん
2008/04/02(水) 10:50:41継承に絡まない型推論はしない主義だから必要になるのかな。
文脈は常に強く型付けされているはずだが。
0634デフォルトの名無しさん
2008/04/02(水) 10:59:040635デフォルトの名無しさん
2008/04/02(水) 11:00:070636デフォルトの名無しさん
2008/04/02(水) 19:35:24本来なら通常は要らんと思うけど、同名のメソッドがオーバーロードされてる
場合必要になるから、必須にしてるんじゃないかな？
0637デフォルトの名無しさん
2008/04/02(水) 19:41:390638デフォルトの名無しさん
2008/04/02(水) 20:49:02ちがうよ。変数スコープが重要
0639デフォルトの名無しさん
2008/04/02(水) 21:46:47contravariant な変換許すなら、型情報だけから必ず判るわけじゃないから
listOfArgumentTypes 省略しないタイプも必要だと思うぞ。
省略できても良いと思うけど。
0640デフォルトの名無しさん
2008/04/02(水) 23:01:51(System.out#println(String)).invoke("Foo")
みたいな場合を考えると必要なケースもあるよってこと
もちろん、必要じゃないケースもあるから省略はできてもいいと思う
もちろん、上のような式を実際に書く必要はないだろうけど、文法上
書けるなら対策は必要になるわけだ
0641デフォルトの名無しさん
2008/04/09(水) 23:28:180642デフォルトの名無しさん
2008/04/10(木) 00:19:260643デフォルトの名無しさん
2008/04/10(木) 00:27:410644デフォルトの名無しさん
2008/04/10(木) 09:45:570645デフォルトの名無しさん
2008/04/10(木) 21:34:28JMFあたりも自動ダウンロードしてくれるならありがたい限りだけどどうだろ。
0646デフォルトの名無しさん
2008/04/18(金) 12:48:24http://download.java.net/jdk7/changes/jdk7-b25.html
http://download.java.net/jdk7/binaries/
0647デフォルトの名無しさん
2008/04/19(土) 06:58:13きれいに書ける構文考えてくれよ。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);}
}
0648デフォルトの名無しさん
2008/04/19(土) 08:59:28しかもクロージャを使って。
0649デフォルトの名無しさん
2008/04/19(土) 09:30:50つ control invocation syntax
0650デフォルトの名無しさん
2008/04/24(木) 14:22:070651デフォルトの名無しさん
2008/04/24(木) 16:03:13素晴らしすぎ。
0652デフォルトの名無しさん
2008/04/24(木) 16:21:190653デフォルトの名無しさん
2008/04/24(木) 17:00:320654デフォルトの名無しさん
2008/04/24(木) 20:05:44そんな時代だと永続性ユニットとしてRDBMSだけじゃなく、
これとMemoryMappedFileあたりと組み合わせたやつとか使いそう。
0655デフォルトの名無しさん
2008/04/24(木) 21:35:450656デフォルトの名無しさん
2008/04/27(日) 15:47:450657デフォルトの名無しさん
2008/04/29(火) 15:06:35http://download.java.net/jdk7/changes/jdk7-b26.html
http://download.java.net/jdk7/binaries/
0658デフォルトの名無しさん
2008/05/04(日) 23:56:54quaereのような式言語っぽいやつじゃなくて言語実装として組み込まれてるのがほしい。
0659デフォルトの名無しさん
2008/05/05(月) 00:12:370660デフォルトの名無しさん
2008/05/13(火) 03:23:42Java一本が難しくなった今、他言語のサポートは急務
LINQみたいなのは、能力的に無理そう。
0661デフォルトの名無しさん
2008/05/16(金) 19:50:57Integer#parseInt(String);のやつ
0662デフォルトの名無しさん
2008/05/20(火) 00:41:53どう考えても負け戦な気がするんだけど。
0663デフォルトの名無しさん
2008/05/20(火) 01:24:560664デフォルトの名無しさん
2008/05/20(火) 23:38:25ただでさえ中心人物がどんどんやめていってるのに
0665デフォルトの名無しさん
2008/05/21(水) 15:16:25開発者のやる気も出るし、Android標準搭載になっていい事だらけだと思うぞ。
まあもらってくれないだろうが・・・
0666デフォルトの名無しさん
2008/05/21(水) 23:37:07デモサイトを見てもブラウザ内で実行できるのが無いんだけど単にJavaFXのブラウザプラグインがまだ無いだけ？
0667デフォルトの名無しさん
2008/05/21(水) 23:43:120668デフォルトの名無しさん
2008/05/21(水) 23:47:01まだ熟してないんだよ。そーあせるなってｗ
0669デフォルトの名無しさん
2008/05/22(木) 00:18:100670デフォルトの名無しさん
2008/05/22(木) 07:10:25知らないだろうけど、フォトランのsun風味とかもあるし、
0671デフォルトの名無しさん
2008/05/23(金) 11:09:35http://download.java.net/jdk7/changes/jdk7-b27.html
http://download.java.net/jdk7/binaries/
0672デフォルトの名無しさん
2008/05/26(月) 12:02:22Tools APIってJDK6で入っただけでまだ標準ライブラリ化してないんだっけ？
0673デフォルトの名無しさん
2008/05/26(月) 12:09:04リッチクライアントプロファイルからはjavacとか削るつもりなんだろ。
プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。
だからTools APIが削られる事と標準かどうかは関係ない。
0674デフォルトの名無しさん
2008/05/26(月) 13:47:38toolsAPIはJREのrt.jarに入ってるから削られる。
0675デフォルトの名無しさん
2008/05/26(月) 14:18:04このスレの主だから。こいつは、なんつーか傲慢で非常にひねくれた性格なのよｗ
確かageたりすると、こいつ、すぐ発狂するからｗｗ
0676デフォルトの名無しさん
2008/05/26(月) 14:20:08だからTools APIが削られる事と標準かどうかは関係ない。
この「だから」ってのはどうつながっていて、標準ライブラリとTools APIとどういう風に「関係がない」のかちゃんと説明できるの？
偉そうに適当な事ばかり言ってないでさ
0677デフォルトの名無しさん
2008/05/26(月) 14:39:12けどjava2Dの一部ってAWTだよな・・・。
0678デフォルトの名無しさん
2008/05/26(月) 14:54:49Ubuntuにheadlessのopenjdkが入って助かった。
でないとサーバ用途なのに、画面周りが必要だったり困りもの。
0679デフォルトの名無しさん
2008/05/26(月) 14:59:420680デフォルトの名無しさん
2008/05/26(月) 15:00:26新java-pluginって単にJavaFXでブラウザからドッカブルにしたかっただけだよね。
J++が吐いた糞バイトコード食ってブラウザ毎VMおとされる心配がなくなったから良いが。
0681デフォルトの名無しさん
2008/05/26(月) 15:09:12ん、そうなんだけど、インストール時はdependencyの関係上画面周りの
インストールが必要だったのよ。使わないのに。
0682デフォルトの名無しさん
2008/05/27(火) 19:24:210683デフォルトの名無しさん
2008/05/27(火) 20:13:570684デフォルトの名無しさん
2008/05/28(水) 19:35:25自分でまねいた種だし、いっちょやっつけちゃってよｗｗ
0685デフォルトの名無しさん
2008/06/01(日) 16:29:28見事に釣り合っております。
0686デフォルトの名無しさん
2008/06/06(金) 19:12:40http://download.java.net/jdk7/changes/jdk7-b28.html
http://download.java.net/jdk7/binaries/
0687デフォルトの名無しさん
2008/06/07(土) 07:16:41build28というのはどのくらいの進捗なの？
クロージャやプロパティは使えるようになってますか？
0688デフォルトの名無しさん
2008/06/07(土) 08:00:59まだまだ。
> クロージャやプロパティは使えるようになってますか？
なってない。
0689デフォルトの名無しさん
2008/06/07(土) 08:02:52クロージャ使いたかったら http://www.javac.info/ のプロトタイプ使うのが手っ取り早い。
0690デフォルトの名無しさん
2008/06/07(土) 12:06:41ありがとう。それは残念、待ち遠しいですね。
0691デフォルトの名無しさん
2008/06/07(土) 14:56:190692デフォルトの名無しさん
2008/06/12(木) 16:02:030693デフォルトの名無しさん
2008/06/12(木) 17:43:41配列で実現する
シンタックスシュガーでいいんだけどな・・・
( String a, String b ) = hoge( c);
が書きたいだけなんだ・・・
Object[] hoge(String c){
}
で定義する、でもいいから・・・
0694デフォルトの名無しさん
2008/06/12(木) 18:45:550695デフォルトの名無しさん
2008/06/12(木) 18:59:38どの辺がバグの温床？
0696デフォルトの名無しさん
2008/06/12(木) 21:14:57var [a, b] = (function (a, b){returen [a, a + b]})(10, 20);
って・・・。
0697デフォルトの名無しさん
2008/06/12(木) 22:44:05ヒープを消費しない形で多用したいので、
組み込みで入れて欲しい。
0698デフォルトの名無しさん
2008/06/12(木) 23:54:09スタック使うのは、何年か前にBugDatabaseでVMの大幅な変更が必要だから却下って言われてたような。
0699デフォルトの名無しさん
2008/06/13(金) 00:54:280700デフォルトの名無しさん
2008/06/13(金) 07:13:100701デフォルトの名無しさん
2008/06/13(金) 10:27:13あれは本当にたちが悪い
0702デフォルトの名無しさん
2008/06/13(金) 10:27:380703デフォルトの名無しさん
2008/06/13(金) 10:36:460704デフォルトの名無しさん
2008/06/13(金) 11:37:270705デフォルトの名無しさん
2008/06/13(金) 11:51:59結構簡単なんじゃないの?
0706デフォルトの名無しさん
2008/06/13(金) 12:30:280707デフォルトの名無しさん
2008/06/13(金) 12:45:290708デフォルトの名無しさん
2008/06/13(金) 13:06:16配列の返値はOKですよね？
0709デフォルトの名無しさん
2008/06/13(金) 13:12:01match case文がないとダサダサだね。
Javaには入りづらいだろうね。
0710デフォルトの名無しさん
2008/06/13(金) 13:30:19戻り値の数と組み合わせの管理が必要になるだろ。
0711デフォルトの名無しさん
2008/06/13(金) 13:35:230712デフォルトの名無しさん
2008/06/13(金) 13:38:09case節で指定できる型を増やしてくれ
0713デフォルトの名無しさん
2008/06/13(金) 13:38:22それはコンパイル時に終わらないかな?
*loadのスロット参照すればいいから。
0714デフォルトの名無しさん
2008/06/13(金) 13:58:13バイトコードベリファイア書き換えないと無理ね。
変更後のバイトコードベリファイアに脆弱性ないかを調べるの面倒だし。
あと、スタックフレームが連続してる保障ないはずだから、
*loadでやるのが可能なのかも疑問だったりする。
0715デフォルトの名無しさん
2008/06/13(金) 14:53:31連続してなくても＊loadで参照できればいいんじゃないのかな。
コンパイル時にフレームサイズもindexも決まるわけだし。
ベリファイア書き換えはちょっと面倒だね。
invokedynamicみたいな基本ポリシーy面での変更はないけれど。
0716デフォルトの名無しさん
2008/06/13(金) 15:08:26るようにするためには、VMの書き換えが必要になるわけで。
0717デフォルトの名無しさん
2008/06/13(金) 15:41:36もちろん実装に任されているけれど。
多値だって個数はスタティックに決まるんだからフレーム内におさめられるし。
>>714は何が疑問なんだろ。
0718デフォルトの名無しさん
2008/06/13(金) 15:44:58VM仕様で、異なるメソッドでフレームが連続していなければならないって記述してある箇所あんの？
0719デフォルトの名無しさん
2008/06/13(金) 16:01:11*returnしたものが、*storeなどで参照できるってことだけだね。
多値が追加されたとしても、その辺の抽象的なVMの定義は変らないのでは。
0720デフォルトの名無しさん
2008/06/13(金) 16:02:24> A frame ceases to be current if its method invokes another method or if its method completes.
> When a method is invoked, a new frame is created and becomes current when control transfers to the new method.
> On method return, the current frame passes back the result of its method invocation, if any, to the previous frame.
> The current frame is then discarded as the previous frame becomes the current one.
あたりを読むと、モデルとしては完全に分離してるように見えるが。
0721デフォルトの名無しさん
2008/06/13(金) 16:03:36Arrayだとdoubleとか入れるの困るじゃん
0722デフォルトの名無しさん
2008/06/13(金) 16:09:55*return した値ってオペランドスタックに置かれるんじゃなかったっけ？
ローカル変数領域だったっけか？
0723デフォルトの名無しさん
2008/06/13(金) 16:23:43java.lang.Doubleにboxingすりゃいいのでは？
>>693みたいな構文糖でいいって場合は配列生成するんだろうし
コストはあんまし重要視してないんじゃないかと。
0724デフォルトの名無しさん
2008/06/13(金) 16:31:45> Object[] hoge(String c){
> }
> で定義する、でもいいから・・・
これはありえんだろ。型弱すぎw
0725デフォルトの名無しさん
2008/06/13(金) 16:35:480726デフォルトの名無しさん
2008/06/13(金) 17:07:14ボクシングの問題とか。
0727デフォルトの名無しさん
2008/06/13(金) 17:18:16そんな謎のpublicなクラス作られると気持ち悪い。
0728デフォルトの名無しさん
2008/06/13(金) 19:54:19で、Genericsのようにチェックはコンパイル時ってことでいいんじゃないかな？
0729デフォルトの名無しさん
2008/06/13(金) 20:45:07そこにタッチ
0730デフォルトの名無しさん
2008/06/13(金) 21:07:15それは思うなぁー
確か7でStringのswitchができるようになるとかいう噂もあったよな
あれは是非お願いしたい。
0731デフォルトの名無しさん
2008/06/13(金) 22:21:24欲しいなと思ってたものが殆ど揃ってる。
0732デフォルトの名無しさん
2008/06/13(金) 22:38:470733デフォルトの名無しさん
2008/06/14(土) 04:51:09http://www.shudo.net/article/SoftwareDesign-200409-MVM/
Javaのメモリ消費問題の解決を目指すSunのプロジェクト「MVM」
http://www.itmedia.co.jp/enterprise/articles/0503/28/news020.html
ついにベールを脱いだ米SunのリアルタイムJava
http://journal.mycom.co.jp/news/2005/07/04/012.html
NASDAQも採用進めるリアルタイムJava
http://japan.zdnet.com/sp/feature/07realtime/story/0,3800078308,20352629,00.htm
Java SEのJVMにマルチタスキング機能とリアルタイム機能が盛り込まれたら
用途がもっと広がると思います。
SUNは自分の商売に使いたいから提供しないのでしょうけど、
コミュニティが独自に開発しないのは何か事情があるのでしょうか？
0734デフォルトの名無しさん
2008/06/14(土) 09:46:140735デフォルトの名無しさん
2008/06/17(火) 01:25:430736デフォルトの名無しさん
2008/06/17(火) 03:53:10JNI必要な応用ばかりじゃないし、
MVMの基準に合致するJNIの制約を作ることも可能。
0737デフォルトの名無しさん
2008/06/17(火) 10:42:44MVMに乗せるアプリは一定基準を守る事って。
Appletだってそうなんだから。
0738デフォルトの名無しさん
2008/06/18(水) 10:54:58Object[]で簡易的にやりたくないなら、
class タプル内部クラス
String a,b;
でいいんじゃないの？これや[]を超える有用なのところがなにかあるのかな。
0739デフォルトの名無しさん
2008/06/18(水) 16:02:150740デフォルトの名無しさん
2008/06/18(水) 17:45:39端的に2つ言うと、
・別にタプルとしてまとめて扱いたい訳じゃない
・見やすいから使いたい
です。
0741デフォルトの名無しさん
2008/06/24(火) 18:54:000742デフォルトの名無しさん
2008/06/26(木) 01:14:36ただ組を表現するのにclass定義とか面倒すぎる
0743デフォルトの名無しさん
2008/06/26(木) 04:34:060744デフォルトの名無しさん
2008/06/27(金) 12:20:21http://download.java.net/jdk7/changes/jdk7-b29.html
http://download.java.net/jdk7/binaries/
0745デフォルトの名無しさん
2008/07/04(金) 08:59:42http://download.java.net/jdk7/changes/jdk7-b30.html
http://download.java.net/jdk7/binaries/
0746デフォルトの名無しさん
2008/07/09(水) 00:37:03パパ「どうだ〜 大画面のプラズマテレビはスゴいだろ〜〜」
ガキ「スゴいね〜 パパ！ これもパパがいつも言ってる愚民からのお金で
買ったの？」
ママ「パパはね、世間がどうなってもたぁ〜くさんお金が貰えるし
ボーナスで毎年プラズマテレビと車も買えるんだからぁ〜〜」
パパ「しかし最近はさぁ〜 マイッタよ、職場が禁煙になっちゃってさぁ〜
なにしろ30分おきに入り口の外までタバコ吸いにいかなきゃならない
んだからなぁ〜、ヘタにそのまま遊びに行くとどこでオンブズマンとか
いう輩が見てるか解らんからなぁ」
ママ「ほんとにあの連中はウジ虫よね！ 自分がなれなかったからって
人の幸せをねたんで」
パパ「まぁ、うちはおじいちゃんの代から公務員だからな、チョロい1次試験
さえクリアすれば2次の面接なんて特攻服で行ったって満点合格なんだ
よ、ハ〜ッハッハッ！」
ママ「ボクもね、大きくなったら公務員になるのよ、一生遊んで暮らせるん
だから〜〜」
ガキ「ウン、ママ！ ボクも公務員になるよ。 ところでさぁ、今年もまた
あのタダの保養所に遊びに行くんでしょ？」
ママ「ママねぇ〜 あそこ飽きちゃったのよ、休みはいくらでもあるんだから
今年はパリにでも行ってお買い物したいわぁ〜〜」
パパ「そうだな〜〜ぁ カラ出勤と合わせれば1ヶ月は軽いしな
よ〜〜し、今年の夏はいっちょう行くかぁ〜〜 ハァ〜、ハッハッハ」
ガキ「ワ〜イ ワ〜イ」
0747デフォルトの名無しさん
2008/07/10(木) 03:18:08そこでなぜObject[]をGenericsで表現しないのか
0748デフォルトの名無しさん
2008/07/10(木) 03:18:51C#と同じノリでいくか。
enumで出来れば十分だろ
0749デフォルトの名無しさん
2008/07/10(木) 22:55:31複数の返値が型が違う場合を考えて。
0750デフォルトの名無しさん
2008/07/10(木) 23:12:29それはT=objectで対処可能。
0751デフォルトの名無しさん
2008/07/10(木) 23:34:21いや、・・・何かGenericsを勘違いしていないか・・・？
0752デフォルトの名無しさん
2008/07/11(金) 05:27:30戻り値が違う場合？
俺の場合はその戻り値の型を同行する前に
自分で型を作って、二つの型に共通するスーパークラスを
作るにふさわしいかどうかを考えるがな。
そうはいかないときもあるが、そういうときは
根本的に設計上の問題があると考えられる。
デザインパターンを考慮するときはとくに。
0753デフォルトの名無しさん
2008/07/20(日) 00:18:11http://download.java.net/jdk7/changes/jdk7-b31.html
http://download.java.net/jdk7/binaries/
0754デフォルトの名無しさん
2008/07/21(月) 16:51:54(String , Map)
こんな二つの結果が帰ってくるときなら、Superclassも何も無いと思うが・・・
0755デフォルトの名無しさん
2008/07/22(火) 21:55:050756デフォルトの名無しさん
2008/07/23(水) 07:28:02> Closures and XML support in Java 7 are unlikely.
だってよ、どーするよ。
0757デフォルトの名無しさん
2008/07/23(水) 08:28:01unlikelyって・・・見込みがないってこと？
0758デフォルトの名無しさん
2008/07/23(水) 09:03:580759デフォルトの名無しさん
2008/07/23(水) 09:17:18実装は http://www.javac.info/ から取ってこれるが。
どっちかっつーと技術的な問題じゃなくて政治的な問題でしょ。
google も http://www.javac.info/google-position.html みたいに及び腰だし。
0760デフォルトの名無しさん
2008/07/23(水) 09:48:43今までのJava(Cの延長）からすればたいぶ異質なパラダイムを入れるのに抵抗があるので、思いのほか大変って意味。
0761デフォルトの名無しさん
2008/07/23(水) 09:57:18英語弱いんで助かりました。
0762デフォルトの名無しさん
2008/07/23(水) 09:58:55パラダイムとか関係ないでしょ。
Javaにclosure入れるっていう根本方針に反対な人が多数派ってんならともかく。
0763デフォルトの名無しさん
2008/07/23(水) 10:00:18orz
0764デフォルトの名無しさん
2008/07/23(水) 10:05:110765デフォルトの名無しさん
2008/07/23(水) 10:07:560766デフォルトの名無しさん
2008/07/23(水) 10:14:55assert とか勝手に予約語に追加しやがるし。
0767デフォルトの名無しさん
2008/07/23(水) 12:43:430768デフォルトの名無しさん
2008/07/23(水) 12:55:23JUnitで使われてた assert って名前のメソッドが改名させられたのは有名な話。
enum って変数名使ってて泣いた奴も案外多かったりして。
0769デフォルトの名無しさん
2008/07/23(水) 13:33:480770デフォルトの名無しさん
2008/07/23(水) 13:38:080771デフォルトの名無しさん
2008/07/23(水) 13:40:21ﾉｼ
0772デフォルトの名無しさん
2008/07/23(水) 15:00:16http://www.vector.co.jp/vpack/browse/pickup/pw5/pw005236.html
0773デフォルトの名無しさん
2008/07/23(水) 15:36:24googleは時期尚早としか書いてないけど、
> To arrive at the best solution, Google is open to multiple parallel investigations
> but is not currently prepared to commit to any particular proposal.
というのは、もしかしたら、data parallelがやりやすいかどうか、
良く確認してから決めたいと考えているのかな。
0774デフォルトの名無しさん
2008/07/23(水) 19:41:05BGGA の初版から 2年、BGGA のver 5出てからもう 1年近くたってるし
未だに時期尚早ってのはなぁ……
Java7 から漏れるそうなのも、jsr166 に closure っつーか
function type 入れたくないよって事なんじゃねーかと邪推したくなる。
doug lea は function type 入れない CICE の提案者の一人だしなぁ。
0775デフォルトの名無しさん
2008/07/24(木) 00:08:410776デフォルトの名無しさん
2008/07/24(木) 00:26:390777デフォルトの名無しさん
2008/07/24(木) 00:27:15まぁListenerの代替として使いたいって程度だから、
Swing Application Frameworkがあれば十分だけど。
代わりといっちゃなんだがOGNL式の静的チェック機能とか欲しい。
0778デフォルトの名無しさん
2008/07/24(木) 05:41:110779デフォルトの名無しさん
2008/07/24(木) 08:01:33その辺は JSR-305 さえ入ってくれれば
@Language("OGNL") とかできるようになるんじゃねーかと思うけど……
0780デフォルトの名無しさん
2008/07/27(日) 02:53:170781デフォルトの名無しさん
2008/07/28(月) 00:10:230782デフォルトの名無しさん
2008/07/28(月) 00:22:280783デフォルトの名無しさん
2008/07/28(月) 00:28:42標準APIは太りすぎだろ
0784デフォルトの名無しさん
2008/07/29(火) 16:07:43土方プログラマ方面では標準化して統一してほしいだろうし。
0785デフォルトの名無しさん
2008/07/29(火) 16:24:350786デフォルトの名無しさん
2008/07/29(火) 17:15:22JDK1.3くらいのときはありがたかったものも今では必要ないとかかなりあるからね
0787デフォルトの名無しさん
2008/07/29(火) 17:35:02後は自分の使いたいクラスライブラリ使う。
0788デフォルトの名無しさん
2008/07/29(火) 17:44:27http://download.java.net/jdk7/jsr203/binaries
しっかし、これ
pfav.setOwner(fs.getUserPrincipalLookupService().lookupPrincipalByName("hoge"));
とか横に長すぎなんですが……
commons-nio が必要になる予感
0789デフォルトの名無しさん
2008/07/29(火) 17:49:12Jakarta Commons VFSに負けちゃうかも…
>>774
CICEはクラス中心的でJavaっぽくていいんだけど、
これだけじゃ物足りないね。
0790デフォルトの名無しさん
2008/07/29(火) 17:52:12control abstractionにまいっちゃってる可能性が…
そうするとBGGA, FCMに吸い寄せられるような
0791デフォルトの名無しさん
2008/07/29(火) 19:23:49生APIってのはそんなもん
だからみんなファサード大量に容易するわけだ
生APIの場合は出来ないことが存在することがまずいわけで
多少のインターフェースの悪さは無視するのが普通かと
0792デフォルトの名無しさん
2008/07/29(火) 19:50:04>>788 の例は、出来る出来ないの話じゃなくて、どっちかっつーとクラス構造(?)の話かな。
UserPrincipal extends java.security.Principal 使う必要があるんか？って話。
setOwner(String) でいいじゃんって思うんだけど。String じゃダメな理由あるんかな？
0793デフォルトの名無しさん
2008/07/29(火) 22:05:32BGGA自体も、関数言語指向の方向性は自然な姿だけど、controlのあれはビックリしたけどね。
なんだかんだ言ってサポートされるからブログとか追いかけて気にし過ぎだなｗ
0794デフォルトの名無しさん
2008/07/30(水) 00:15:33ネストしたときのわけわからなさは異常
1つのメソッドのみのインターフェースを書くのがだるい人向けかな
業務系だと型そのものが大事ではなくてインターフェース名そのものが大事だから
あんまり使われないと思う
0795デフォルトの名無しさん
2008/07/30(水) 00:37:34クロージャも同じように使ってるうちに全く想定外の使い方がでてくるんじゃないの。
interface Inte <T extends java.lang.Number>
{
int compareTo(T obj);
}
Inte<BigDecimal>だとobj.subtract(this)とかできる。
0796デフォルトの名無しさん
2008/07/30(水) 01:22:10日本語でもうちょっとわかりやすく
0797デフォルトの名無しさん
2008/07/30(水) 01:33:57それなんか意味あるの？
0798デフォルトの名無しさん
2008/07/30(水) 02:18:49> 土方プログラマ
が エア プログラマ にみえたので眼鏡を新調してくる。
0799デフォルトの名無しさん
2008/07/30(水) 05:00:44おまえのそのメガネは高く売れる。
0800デフォルトの名無しさん
2008/07/30(水) 05:12:58正解です
0801デフォルトの名無しさん
2008/07/30(水) 09:18:27これ java.nio.file.Path がディレクトリか調べるのに旧I/O使わないと
path.getFileAttributeView(BasicFileAttributeView.class, true).readAttributes().isDirectory()
とかする必要あるんですが……
旧I/O使うと new File(path.toUri()).isDirectory() で済むけど
旧I/Oだと java.io.File#getPath() で帰ってくるのが java.nio.file.Path っぽいけど、
実は String だとか名前の統一性なくなるからあんまし混ぜたくないんだよなぁ
0802デフォルトの名無しさん
2008/07/30(水) 12:00:59http://blogs.sun.com/abuckley/en_US/date/20080728
module を言語全体のキーワードでなく文脈依存のローカルキーワードにしたいんだけど、例えば
class classname { module classname(){ throw new Error(); } }
って宣言があった場合、module型を返すメソッドなのか
module privateなコンストラクタなのか判別付かなくて悩ましいというお話。
互換性だけを考えると module型を返すメソッドにするべきなんだろうけど……
0803デフォルトの名無しさん
2008/07/30(水) 14:08:05おまえの知能を疑うが、どこを日本語にして分かりやすくして欲しいんだ？
0804デフォルトの名無しさん
2008/07/30(水) 15:34:07>>795のどこが不思議な使い方なんだ?
0805デフォルトの名無しさん
2008/07/30(水) 15:52:280806デフォルトの名無しさん
2008/07/30(水) 18:02:10お前らの頭の中は不思議でいっぱい
0807デフォルトの名無しさん
2008/07/30(水) 18:42:40あれは面倒くさかった。
ぜんぶassert()メソッドをassertEquals()やassertNotTrue
とかに変更する羽目になった
0808デフォルトの名無しさん
2008/07/30(水) 18:44:49Log4jかな。あれを標準化したロギングAPIと統合して欲しい。
ライブラリ依存関係で混乱するから。
Commons Math、Commons Collections、Commons Configurations
も標準APIにいれて欲しい
0809デフォルトの名無しさん
2008/07/30(水) 18:48:12CollectionsのGenerics対応はまだまだ遅いよな。
別ライブラリとしてGenerics対応されたやつがあるだけで
まだまだ時間かかりすぎる。
0810デフォルトの名無しさん
2008/07/30(水) 18:53:190811デフォルトの名無しさん
2008/07/30(水) 19:03:070812デフォルトの名無しさん
2008/07/30(水) 19:44:09単純型名で module型が使える場合は module型を返すメソッド、
そうでなければ module privateなコンストラクタってのはダメなんかね？
module型使ってる場合は module privateなコンストラクタを一切使えなくなるけど、
それはmodule privateな静的ファクトリメソッド使うなりして我慢してもらう方向で。
0813デフォルトの名無しさん
2008/07/30(水) 20:52:30いや。十分にマ版ネタだと思うが。
0814デフォルトの名無しさん
2008/07/30(水) 21:04:53package名前空間使って
public package FacadePackage {
public class FacadeClass {
}
private class SomeClass {
}
private package SomePackage {
private class SomeClassB {
}
}
}
んなFacadeなパッケージを作れないだろうか。
UMLで登場したことがある「Facadeに相当するパッケージ」を
作れないかと期待。
今まではクラスレベルでしかできなかったことがパッケージレベルでも
出来ればと期待。
0815デフォルトの名無しさん
2008/07/30(水) 21:05:42キーワードが増えてこまったこととか、CollectionsのGenerics対応とか、技術ネタだろ。マ板にもっていく必要性がわかんない。
0816デフォルトの名無しさん
2008/07/30(水) 21:51:130817デフォルトの名無しさん
2008/07/30(水) 21:59:290818デフォルトの名無しさん
2008/07/30(水) 22:02:04まぁ、落ち着けよ。
宿題やったか？早いうちに終わらせとけよ。
0819デフォルトの名無しさん
2008/07/30(水) 22:15:07module で export package 指定できりゃそれで良いんじゃ？
0820デフォルトの名無しさん
2008/07/31(木) 00:52:21早く死ねよ
0821デフォルトの名無しさん
2008/07/31(木) 01:48:01それはC/C++のヘッダファイルと同じ運命を辿らないか？
できればimport宣言はそのクラス内ですませたい
0822デフォルトの名無しさん
2008/07/31(木) 03:08:13ITドカタは来えろ
0823デフォルトの名無しさん
2008/07/31(木) 08:22:28> それはC/C++のヘッダファイルと同じ運命を辿らないか？
ってどーゆー事？
「export うんたら」 はモジュール外から使えるクラス「うんたら」だけに制限する。
>>814 みたいな事は OSGi の Export-Package 使えばできるんじゃね？って思うんだが。
JSR-277 はそこんとこはクラス単位みたいだけど
それを パッケージ単位でもできるようにすれば良いだけのよーな。
0824デフォルトの名無しさん
2008/07/31(木) 10:03:56Attributes.getBasicFileAttributes(path, true).isDirectory() までは短くなるな。
十分長いよーな気もするけど。
new File(path.toUri()).isDirectory() に比べても、まだ長いし。
0825デフォルトの名無しさん
2008/07/31(木) 10:12:33そんな事するぐらいなら module を言語全体に影響するキーワードにした方がすっきりせんか？
変数名とかフィールド名にmoduleって名前使ってる人には泣いてもらう事になるけど。
0826デフォルトの名無しさん
2008/07/31(木) 11:51:29VM作ってるぐらいだからやる気になればそう難しくなさそうですが
本末転倒かな便利だと思うけど
0827デフォルトの名無しさん
2008/07/31(木) 11:59:58スレ違いのレベルも下がったな。夏休みか。gcjでも食ってろ蛸。
0828デフォルトの名無しさん
2008/07/31(木) 12:13:47スレ違いのレベルも下がったな。夏休みか。Visual J#でも食ってろ蛸。
0829デフォルトの名無しさん
2008/07/31(木) 12:47:130830デフォルトの名無しさん
2008/07/31(木) 12:49:15影響範囲がでかすぎる。
assertのときほどJavaはマイナーではないし、enumほどみんなに使われるわけでもない。
ほとんどの人が直接使わないのにキーワードにされたら、そりゃ怒るだろね。
0831デフォルトの名無しさん
2008/07/31(木) 13:05:12moduleって名前使ってない人は怒らないから大丈夫。
それに列挙型よりはモジュール機能の方が使用頻度高いと思うが。
言語仕様汚れる方が将来の言語拡張の妨げになるから嫌って人も多いし。
0832デフォルトの名無しさん
2008/07/31(木) 13:09:29そこに 2つ目の案として
class classname { module classname(){ throw new Error(); } }
はmodule privateなコンストラクタで、package privateなmodule型を返すメソッドは
class classname { package module classname(){ throw new Error(); } }
にしろって案が出てるけど、これも結構汚いよなぁ。
現実的ともいえるけど。
0833デフォルトの名無しさん
2008/07/31(木) 13:26:23使いものになんねーだろあれ
0834デフォルトの名無しさん
2008/07/31(木) 14:11:320835デフォルトの名無しさん
2008/07/31(木) 14:52:330836デフォルトの名無しさん
2008/07/31(木) 15:58:31言ってることが良く分からないんだけど、どの言語仕様が汚くなるの？
0837デフォルトの名無しさん
2008/07/31(木) 16:56:07全体にキーワード適用した方が言語仕様が単純に保てて汚れずに済むって話。
>>812みたいな小細工が汚れそのもの。
0838デフォルトの名無しさん
2008/07/31(木) 16:57:51今後の言語拡張だけじゃなくてコンパイラの単純さ健全さバグの少なさにも影響してくるし。
0839デフォルトの名無しさん
2008/07/31(木) 19:27:080840デフォルトの名無しさん
2008/07/31(木) 19:48:45抽象的で分からないんだけど、もうちょっと具体的に技術的な話は出来ないの？
0841デフォルトの名無しさん
2008/07/31(木) 22:33:06お前、このスレ来るのまだ早いよ。
0842デフォルトの名無しさん
2008/07/31(木) 22:40:070843デフォルトの名無しさん
2008/07/31(木) 23:34:18言語仕様に追加する場合考えてみ？
全体キーワードなら 3.9 Keywords に module 加えればいいだけ。
>>812 をやろうとすると、大量に書き換えが必要になる。
0844デフォルトの名無しさん
2008/08/02(土) 17:57:54もう全体キーワードの追加は認められないだろね。
moduleなんてパッケージ名はどこにでもありそうだし。
言語処理側ががんばればいいのなら、それでやるべきだと思う。
0845デフォルトの名無しさん
2008/08/02(土) 19:36:500846デフォルトの名無しさん
2008/08/02(土) 19:53:09OSGi との互換性とか整合性とかどーすんだろね？
なんつーか >>763 の予感が……
0847デフォルトの名無しさん
2008/08/02(土) 22:25:45それなんてCloneable？
0848デフォルトの名無しさん
2008/08/02(土) 23:17:360849デフォルトの名無しさん
2008/08/03(日) 01:27:020850デフォルトの名無しさん
2008/08/03(日) 01:35:260851デフォルトの名無しさん
2008/08/03(日) 02:35:050852デフォルトの名無しさん
2008/08/03(日) 03:07:57スレ違い
0853デフォルトの名無しさん
2008/08/03(日) 03:25:49スレ違い
0854デフォルトの名無しさん
2008/08/03(日) 04:14:44スレ違い
0855デフォルトの名無しさん
2008/08/03(日) 05:46:060856デフォルトの名無しさん
2008/08/03(日) 07:20:310857デフォルトの名無しさん
2008/08/03(日) 07:28:50そう思いたい。
0858デフォルトの名無しさん
2008/08/03(日) 08:08:300859デフォルトの名無しさん
2008/08/03(日) 11:18:41夏だからしょうがないか
0860デフォルトの名無しさん
2008/08/03(日) 14:00:570861デフォルトの名無しさん
2008/08/03(日) 14:23:470862デフォルトの名無しさん
2008/08/03(日) 16:32:200863デフォルトの名無しさん
2008/08/03(日) 17:20:09英語のページだと悲観的見解が多い。
やっぱりいつまでも指をくわえて待ってないで、C#とか既にあるのを使えばいいんじゃないか。C#は使ったことないけど・・
0864デフォルトの名無しさん
2008/08/03(日) 17:30:44どこ？
0865デフォルトの名無しさん
2008/08/03(日) 17:33:42break と continue は、また今度らしい。
http://mail.openjdk.java.net/pipermail/closures-dev/2008-August/000190.html
0866デフォルトの名無しさん
2008/08/03(日) 17:47:20nonlocal return すると例外吐いてコンパイラ落ちるんだが。
>>788 の NIO2のEA版じゃなくて、正規のjdk1.7使わんと駄目なんだろうか？
0867デフォルトの名無しさん
2008/08/05(火) 10:14:55これで今のところ予定してる機能はコンプリートしたらしい。
http://mail.openjdk.java.net/pipermail/closures-dev/2008-August/000193.html
>>866
今回のは >>788 の NIO2のEA版でも大丈夫だったぞ。
0868デフォルトの名無しさん
2008/08/05(火) 12:39:280869デフォルトの名無しさん
2008/08/05(火) 16:05:52www.javac.info つながらなくね？
0870デフォルトの名無しさん
2008/08/05(火) 19:52:570871デフォルトの名無しさん
2008/08/08(金) 03:53:55おまえが馬鹿だからじゃね？
0872デフォルトの名無しさん
2008/08/09(土) 05:22:270873デフォルトの名無しさん
2008/08/09(土) 10:02:240874デフォルトの名無しさん
2008/08/09(土) 10:29:07スレ違いなんだよアホ
0875デフォルトの名無しさん
2008/08/09(土) 12:33:000876デフォルトの名無しさん
2008/08/09(土) 13:04:310877デフォルトの名無しさん
2008/08/10(日) 00:24:57C++すらも使いこなせないんですか？
0878デフォルトの名無しさん
2008/08/10(日) 02:00:13またお前か・・・
0879デフォルトの名無しさん
2008/08/10(日) 02:15:14だれのことだよｗ
0880デフォルトの名無しさん
2008/08/10(日) 02:16:530881デフォルトの名無しさん
2008/08/10(日) 02:45:480882デフォルトの名無しさん
2008/08/10(日) 03:28:36こういう奴はよく沸いてくるんだけど、どこかの糞溜めに消えてくれないか？
0883デフォルトの名無しさん
2008/08/10(日) 09:17:410884デフォルトの名無しさん
2008/08/10(日) 09:20:260885デフォルトの名無しさん
2008/08/10(日) 13:03:510886デフォルトの名無しさん
2008/08/10(日) 14:06:440887デフォルトの名無しさん
2008/08/10(日) 16:34:31レイヤーからして違う。
0888デフォルトの名無しさん
2008/08/10(日) 17:17:130889デフォルトの名無しさん
2008/08/10(日) 21:55:32経営者以外は土方みたいなもんだ。
自分のやることにちったー誇りもてよ？
0890デフォルトの名無しさん
2008/08/10(日) 23:47:00そっちでならスレを指定すれば
話に加わってもいいよ。
ここではマ板な話はスルー。
>>865
RPMよりyumのように扱えれば便利だよね。
それもMavenですでに実現しているかな？
0891デフォルトの名無しさん
2008/08/11(月) 01:18:14経営者なんて、外じゃペコペコ頭下げて、無理な要求持ってきて迷惑なだけじゃん。
人として感情をもってないペコちゃん人形と同じだな。
0892デフォルトの名無しさん
2008/08/11(月) 02:37:05これは・・・
0893デフォルトの名無しさん
2008/08/11(月) 04:01:450894デフォルトの名無しさん
2008/08/11(月) 04:24:580895デフォルトの名無しさん
2008/08/11(月) 07:49:00丁度いいスレがあったから紹介しておくよ
ITﾍﾞﾝﾁｬｰ経営者だがそろそろ畳もうと思う
http://pc11.2ch.net/test/read.cgi/prog/1198225909/
0896デフォルトの名無しさん
2008/08/11(月) 09:33:150897デフォルトの名無しさん
2008/08/11(月) 10:40:010898デフォルトの名無しさん
2008/08/11(月) 12:04:240899デフォルトの名無しさん
2008/08/11(月) 12:43:350900デフォルトの名無しさん
2008/08/12(火) 00:53:150901デフォルトの名無しさん
2008/08/15(金) 02:59:03ギャグが現実化すればのう
0902デフォルトの名無しさん
2008/08/17(日) 11:48:43http://download.java.net/jdk7/changes/jdk7-b33.html
http://download.java.net/jdk7/binaries/
0903デフォルトの名無しさん
2008/08/28(木) 22:27:20なんだよあの関数型w
宣言とか仮引数にいちいちあんなの書いてられるか
インタフェースへのキャストも糞仕様としか思えない
メソッド定義が一つの時だけできるとかまともな設計センスじゃないだろ
0904デフォルトの名無しさん
2008/08/28(木) 22:32:38まずは仕様をちゃんと読め。それから。
0905デフォルトの名無しさん
2008/08/28(木) 22:50:09ちょっと誤解してたわ
引数が同じものがあったらダメってことか
どっちにしても分かりにくい上にわざわざこんなことしてまで使いたくないな
0906デフォルトの名無しさん
2008/08/28(木) 22:55:18他の言語のプラットフォームとしてがんばってくれれば。
俺はScalaに逝く。
0907デフォルトの名無しさん
2008/08/28(木) 22:59:08言語仕様そのものはシンプルだし、GenericsやAnnotationの類が
もう２，３種増えないとリファクタリングの効果が薄い気がする。
0908デフォルトの名無しさん
2008/08/28(木) 23:01:20素直にfunction予約語かなんか導入して
function F(int i, int s);
F f = { int x, int y => x +y };
f(10, 20);
とか
function F(int i, int s) { x +y }
F f = new F();
f(10, 20);
にできなかったのか？
0909デフォルトの名無しさん
2008/08/28(木) 23:04:55単純でいいなぁ
0910デフォルトの名無しさん
2008/08/28(木) 23:13:59とっくに議論尽くされて今の仕様まで来たんだけ、全然知らないくせに横から口出すなよ。
おまえはscla使ってれ。たいした差はないと思うけどなｗ
0911デフォルトの名無しさん
2008/08/28(木) 23:16:57F f = new F();
f(10, 20);
これなんか、クラス宣言をちょっとだけ省略した普通の関数（クラス）の宣言じゃんｗ
アノニクラスと一緒にしてるみたいだし、おまえアホだろ？
0912デフォルトの名無しさん
2008/08/28(木) 23:24:53interface F {
int f1(int x, int y);
String f2(int x, int y);
}
F f = { int x, int y => x + y };
f(.invoke(10, 100);
とか
{ int, int => int } f = { int x, int y => x + y };
f(.invoke(10, 100);
書いててばかばかしいと思わん？
0913デフォルトの名無しさん
2008/08/28(木) 23:37:230914デフォルトの名無しさん
2008/08/28(木) 23:38:33関数が多言語使ってるくせに、数学のことまるっきり分かってないようだなｗ
おまえばかだろ？
0915デフォルトの名無しさん
2008/08/28(木) 23:49:47int f1(int x, int y);
String f2(int x, int y);
}
F f = { int x, int y => x + y }; //あれぇ、ブロック要素なのにオブジェクト扱い？
f(.invoke(10, 100); //わざわざinvoke()を特別扱い。インタフェースには定義ないし、きもいね
とか
{ int, int => int } f = { int x, int y => x + y }; //{ int, int => int }って、こんなの持ち回るんかい！
f(.invoke(10, 100);
もうねinvokeの特別扱いとかいろいろ導入してんだよ
こんなことやるくらいならもっといろいろできただろ
>>914
数学（笑）
頭いいならさ説明してみろよ
0916デフォルトの名無しさん
2008/08/29(金) 00:44:01関数型言語を使ってれば数学チックな思考を出来るようになっていてもいいんじゃないの？
0917デフォルトの名無しさん
2008/08/29(金) 00:45:29君が糞だって事はよーく分かったからｗｗ
0918デフォルトの名無しさん
2008/08/29(金) 00:47:160919デフォルトの名無しさん
2008/08/29(金) 01:00:250920デフォルトの名無しさん
2008/08/29(金) 01:09:46ある意味Javaの先輩といってもいいくらいの。
0921デフォルトの名無しさん
2008/08/29(金) 01:27:200922デフォルトの名無しさん
2008/08/29(金) 01:28:100923デフォルトの名無しさん
2008/08/29(金) 02:27:58言語仕様はSUNがびしっと決めてしまったほうがましな気がするな。
船頭多くしてなんとやらだよ、まったく。
0924デフォルトの名無しさん
2008/08/29(金) 02:30:48Javaはtypedefはやらない流儀。別名を導入しない。
function F(int i, int s);は別名導入しているに等しい。
0925デフォルトの名無しさん
2008/08/29(金) 02:39:150926デフォルトの名無しさん
2008/08/29(金) 02:47:55{int o => o<=1 && o>=-1} なんか笑われてるようにしか見えないじゃんか。
もうJAVA終わったorz
0927デフォルトの名無しさん
2008/08/29(金) 03:04:36個人的にはfunction typeの構文がかなり可読性を下げる気がするのでやめて欲しい。
型名書いているのかブロック書いているのか分からなくなる。
0928デフォルトの名無しさん
2008/08/29(金) 03:08:360929デフォルトの名無しさん
2008/08/29(金) 03:22:29糞だからな
0930デフォルトの名無しさん
2008/08/29(金) 03:54:34お前の可読性の好みなど聞いてない
0931デフォルトの名無しさん
2008/08/29(金) 06:23:440932デフォルトの名無しさん
2008/08/29(金) 10:29:240933デフォルトの名無しさん
2008/08/29(金) 16:01:030934デフォルトの名無しさん
2008/08/29(金) 17:19:05s/JAVA/KABA/ だめだこりゃ
0935デフォルトの名無しさん
2008/08/29(金) 17:19:220936デフォルトの名無しさん
2008/08/29(金) 19:42:34おまえはクロージャのインタフェースへのキャスト仕様理解してから話せ
0937デフォルトの名無しさん
2008/08/29(金) 20:07:04KABAはPrologだけど、知らないんだろうな・・・
0938デフォルトの名無しさん
2008/08/29(金) 20:43:30未だにIISオンリーで糞重C#とか、化石のVBとか、MatzクンのオナニーRubyとか？
ねーよｗｗありえねーわｗｗｗｗｗｗ
0939デフォルトの名無しさん
2008/08/29(金) 22:12:36CやVBは化石なんじゃなくて歴史があるってもんよ。
C#なんか常々進化してんじゃん。
それを言うならjavaの方がもう化石なんじゃねーの？
0940デフォルトの名無しさん
2008/08/29(金) 23:10:222年に一度は大きいアップデートがある（EEも含めると毎年ある）環境だというのに
昔の言語と違って今の言語はどれも大幅な更新が入るのは当たり前だぞ
0941デフォルトの名無しさん
2008/08/29(金) 23:15:420942デフォルトの名無しさん
2008/08/29(金) 23:19:280943デフォルトの名無しさん
2008/08/30(土) 06:01:480944デフォルトの名無しさん
2008/08/30(土) 06:40:380945デフォルトの名無しさん
2008/08/30(土) 11:32:40しばらくの辛抱だw
0946デフォルトの名無しさん
2008/08/30(土) 23:25:580947デフォルトの名無しさん
2008/08/31(日) 02:10:450948デフォルトの名無しさん
2008/08/31(日) 02:39:310949デフォルトの名無しさん
2008/08/31(日) 08:45:43こんなスレに興味を抱いた俺が馬鹿だったわ
0950デフォルトの名無しさん
2008/08/31(日) 09:00:310951デフォルトの名無しさん
2008/08/31(日) 10:30:15おまえのような糞に言われたくない罠
0952デフォルトの名無しさん
2008/09/01(月) 12:25:27その辺の返し方がクソスレｗｗ
0953デフォルトの名無しさん
2008/09/01(月) 17:29:50ソースコードが読みにくくなるんだよ
0954デフォルトの名無しさん
2008/09/01(月) 20:08:09糞は無理して発言しなくていいよ。それよか、海外でもいいから、ねたブログとかないの？
0955デフォルトの名無しさん
2008/09/01(月) 21:09:19interface F {
int f1(int x, int y);
String f2(int x, int y);
}
F f = { int x, int y => x + y };
f.invoke(10, 100);
なんだよこれ
0956デフォルトの名無しさん
2008/09/01(月) 21:40:54おまえ、あたま大丈夫？
0957デフォルトの名無しさん
2008/09/01(月) 23:14:13これってメソッドが2つあるからコンパイルエラーでは?
なんか問題あるの?
0958デフォルトの名無しさん
2008/09/01(月) 23:37:41ところが仕様ではこれがOKなのさ
驚きだろ？
0959デフォルトの名無しさん
2008/09/02(火) 03:31:21そして、どのくらいの頻度で、問題のある動きになるのかな？
メリットはかなり大きいと思うが、割りにあうのかないのか
0960デフォルトの名無しさん
2008/09/02(火) 03:33:35それならもうC#しかないな。C#でもDでもいいから、一緒にやらないか？
0961デフォルトの名無しさん
2008/09/02(火) 03:42:200962デフォルトの名無しさん
2008/09/02(火) 03:52:42でもグルービーと比べるとイマイチ違いがないんだよね（言語機能じゃなくて）。
グルービーはJSRで仕様堅めに入ってるから先が見込めるけど、scalaは（言語機能じゃなくて）普及の兆しを感じないな。
個人的にはjdk1.6で既にサポートされてるrhinoでいいんじゃないかと思う。
0963デフォルトの名無しさん
2008/09/02(火) 04:00:21しかもrhinoでいいんじゃないかとかいう。
その言語で作ったクラスをJavaで自由に扱えるかどうかも、でかいとおもうよ。
0964デフォルトの名無しさん
2008/09/02(火) 04:04:130965デフォルトの名無しさん
2008/09/02(火) 04:05:430966デフォルトの名無しさん
2008/09/02(火) 06:29:380967デフォルトの名無しさん
2008/09/02(火) 06:34:55言語仕様も大事だが、大手のサポートやツールの有無
つまり周辺環境がないとどうしようもない
今んところ実質的な代替はC#にしかできないでしょ
あとはRubyがちょっと流行ったくらい
JavaがgdgdになるならScalaもありかもしんないけど
企業向けに立ち上がるにはよほど運がないと無理でしょ
0968デフォルトの名無しさん
2008/09/02(火) 06:39:28まあ、このスレはこの程度かｗ
0969デフォルトの名無しさん
2008/09/02(火) 06:42:36Scalaはスクリプトサポートではなく、Java言語の代替として使うことを考えられてる。
だから静的コンパイルされてクラスファイルを生成して動かす。
そうすると、Javaと同等かそれ以上の速さで動く。
クラスファイルだから、Javaからも比較的自由に使える。つまり特別な仕組みを使わなくてもServletやJPAのクラスが作れるということ。
部分的な適用がやりやすくなる。
で、今は、Javaの言語仕様拡張よりScalaじゃねぇの？って文脈。Javaの代わりになるかという話。
>>967
企業向けのエンドプログラマはJava1.4で充分でしょ。
0970デフォルトの名無しさん
2008/09/02(火) 06:43:38Javaになんでもかんでも詰め込んで欲しいとは思わん
0971デフォルトの名無しさん
2008/09/02(火) 07:14:40こういう俺様俺様ってのはどこにでもいるよなｗｗC++なんかこんな奴らの固まりだしｗｗ
0972デフォルトの名無しさん
2008/09/02(火) 07:17:440973デフォルトの名無しさん
2008/09/02(火) 08:04:160974デフォルトの名無しさん
2008/09/02(火) 08:19:550975デフォルトの名無しさん
2008/09/02(火) 10:45:010976デフォルトの名無しさん
2008/09/02(火) 17:12:24v0.5って仕様にはclosure conversionはsingle methodを持つもの、
って書いてあるのでそのケースはエラーになると思ったんだけど、どっか他に仕様がある?
呼ばれるメソッドが不定に見えるのでエラーにするのが普通だと思うんだが。
あと最後のinvokeはFがinvoke持ってないからエラーになるような。invokeに関しては、function typeがinvokeを持つinterfaceとして扱われるのでは。
0977デフォルトの名無しさん
2008/09/02(火) 20:35:43定期的にアップグレードする計画を立てるのもシステム課の重要な仕事だな。
0978デフォルトの名無しさん
2008/09/02(火) 20:51:020979デフォルトの名無しさん
2008/09/02(火) 21:15:02それが普通だよなw
インタフェースのメソッドは一つらしい
でも例外的に他のメソッドの引数がObjectのときはOK
つまり正しくは以下のコードだったよ
interface F {
int f1(int x, int y);
String f2(Object x, Object y);
}
F f = { int x, int y => x + y };
f.invoke(10, 100);
invokeはクロージャを実行する特別メソッド
インタフェースとは全然関係ない
だから以下のように書けるようだ
{ int x, int y => x + y }.invoke(10,20);
これもなんだかどうしようもないよな
最初の例見ると可読性ないよw
0980デフォルトの名無しさん
2008/09/02(火) 21:18:48部署に一台、事務処理専用マシンを作っていくのは基本だろ？
interface F {
int f1(int x, int y);
String f2(Object x, Object y);
}
class MyClass implements F{
int f1(int x, int y){
return x + y;
}
String f2(Object x, Object y){
return x.toString() + y.toString();
}
}
F f = new MyClass();
f.invoke(2,3);
0982デフォルトの名無しさん
2008/09/02(火) 21:50:23それは無理だよ
どこにもクロージャ使ってないでそ
0983デフォルトの名無しさん
2008/09/02(火) 22:31:580984デフォルトの名無しさん
2008/09/02(火) 22:56:470985デフォルトの名無しさん
2008/09/02(火) 23:09:290986デフォルトの名無しさん
2008/09/02(火) 23:18:100987デフォルトの名無しさん
2008/09/02(火) 23:24:08その仕様はどこに書いてあるん?
なんでその例外的ルールがあるのかわらない。
それから、
F f = { int x, int y => x + y };
f.invoke(10, 100);
これはFがinvokeを持ってないので無理でしょ?
invokeはclosure literalが持つってだけで、特別なメソッドではないでしょ?
(だから>>981は無理なはず)
{int x, int y => x+y }.invoke(10,100)ができるのは分かる。
これはclosure literalがinvoke(int,int)を持つ型なので。
function typeがinvokeを持ってて、他のinterfaceの型に変換するときにそのinterfaceの持つ1つのメソッドに割り当てられるってことでは。
あと、literalに直接invoke呼ぶのはそんなに無いんじゃないだろうか。
0988デフォルトの名無しさん
2008/09/02(火) 23:32:57プロパティ構文が一番じゃね?
0989デフォルトの名無しさん
2008/09/02(火) 23:36:31どうせスカラー云々スクリプト云々って奴だろｗ
こいつの頭の中ではごっちゃになってて、サル脳だから理解できないんだろうｗｗ
0990デフォルトの名無しさん
2008/09/02(火) 23:58:48たいして仕様を読んでないようなサルの相手をすることもないんじゃないの？
君も同じく相当ヒマだろうけどｗ
0991デフォルトの名無しさん
2008/09/03(水) 01:37:330992デフォルトの名無しさん
2008/09/03(水) 01:39:55なら仕様を読みまくってる君が簡潔に説明してみたらいいのではないだろうか
なんでここ見てるわけ？
0993デフォルトの名無しさん
2008/09/03(水) 01:45:49くやしいのｗｗｗくやしいのｗｗｗｗｗｗ
0994デフォルトの名無しさん
2008/09/03(水) 02:12:41知らねぇのに無理して使うなよ。ほしのあきじゃねぇんだから。
くやしいのうｗｗｗ
0995デフォルトの名無しさん
2008/09/03(水) 02:37:51ゴミはまだ常任してんのか。
おまえのうんちくはイランから、はよ死ね。
0996デフォルトの名無しさん
2008/09/03(水) 02:42:120997デフォルトの名無しさん
2008/09/03(水) 03:00:33次スレもいらんわｗ
0998デフォルトの名無しさん
2008/09/03(水) 03:01:51そんな雑学よりも、英語をみっちり勉強した方が自分スキル向上になるんじゃないでしょうか？
0999デフォルトの名無しさん
2008/09/03(水) 03:02:38逝 っ て よ し ｗ
1000デフォルトの名無しさん
2008/09/03(水) 03:20:241001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。