【Java SE 7】次世代Javaの動向７【dolphin】

【Java SE 7】次世代 ..

369:デフォルトの名無しさん
09/01/08 23:15:57
>>365
おんなじJavaを使っても、クロージャを使ったことがある人は困って、
使ったことがない人は困らない？
そりゃ変な理屈だろう。

370:デフォルトの名無しさん
09/01/08 23:19:38
携帯電話のない世界に住む人が携帯電話がなくて困るわけがないだろう

371:デフォルトの名無しさん
09/01/09 00:00:27
クロージャのない言語はクソ

372:デフォルトの名無しさん
09/01/09 00:05:46
Control invocation syntax 萌え
ビバ、BGAA！

373:デフォルトの名無しさん
09/01/09 01:56:22
>>369-370
今日のベストアンサー賞

374:デフォルトの名無しさん
09/01/09 22:16:10
しかしJavaが和暦に対応したばっかりなのにもう平成が終わりそうだよ！

375:デフォルトの名無しさん
09/01/09 23:45:01
でも、携帯電話があったらなぁ、と夢想はする。

376:デフォルトの名無しさん
09/01/10 02:22:33
>>370
それはクロージャが携帯電話みたいに一度使ったら手放せないほど
便利だという前提での話だね。
アマチュア無線だったらまぁ、あれば便利なんだろうけど、それがない
世界に行っても俺は困らないや。

377:デフォルトの名無しさん
09/01/10 06:01:33
クロージャーは便利だね。一度クロージャーがある環境になれると、クロージャーなしの環境は不便。
クロージャーがある環境というのは、文法がクロージャーに対応してるだけじゃなくて、ライブラリもクロージャー前提になってるのな。

378:デフォルトの名無しさん
09/01/10 07:48:37
クロージャがあれば苦労しなくて済む

379:デフォルトの名無しさん
09/01/10 08:09:06
クロージャはJavaFx Scriptで使えるから暫くはこれで遊んでいよう。

380:デフォルトの名無しさん
09/01/10 08:23:56
しかし、
クロージャは入らない

残念ｗ

381:デフォルトの名無しさん
09/01/10 10:07:36
java7は地味なリリースになりそうだな・・・
目新しいのはJAMぐらい？

382:デフォルトの名無しさん
09/01/10 12:40:04
クロージャって便利何だけど、今のjavaに自然に含める文法を考えるのが相当難しいんだよな。
正直 => みたいな文字が入るぐらいなら無いほうがマシって気にもなる。

まぁ、ジェネリクスの<>も最初拒否反応出たけどすぐになれたから、すぐになれるものなのかもしれないけど。

383:デフォルトの名無しさん
09/01/10 12:49:50
クロージャでクロー知らずジャ

384:デフォルトの名無しさん
09/01/10 13:16:59
button.Click += (sender, e) => {
　var averageAge = persons.Where(p => p.Sex == local_Sex).Select(p => p.Age).Average();
　MessageBox.Show(averageAge.ToString());
}
今のC#なんかこんなことになってるからなw

385:デフォルトの名無しさん
09/01/10 13:26:04
やっぱり
+=
これにはとても抵抗があるな。パッとみ、Clickの回数を+=するとも見えるし、
オーバーロードと分かっていても抵抗がある。

386:デフォルトの名無しさん
09/01/10 13:28:32
ただ、こういうの（簡略表記というか）はjavafxの方に流れてるからなぁ。

387:デフォルトの名無しさん
09/01/10 13:30:10
>>385
オーバーロードは違うな
プロパティと一緒だよ
プロパティに=を使ったらgetter/setterアクセサメソッドの呼び出しになるでしょ
それと同様に，+=はaddアクセサ，-=はremoveアクセサの呼び出し

388:デフォルトの名無しさん
09/01/10 13:48:08
javafxだとイベント系の処理はクロージャよりbindで済ませることが多いかな。

389:デフォルトの名無しさん
09/01/10 14:30:06
今落ち着いて考えると、
ジェネリクスはいらなかったと思うんだ

390:デフォルトの名無しさん
09/01/10 14:32:43
いやさすがにそれはない

391:デフォルトの名無しさん
09/01/10 14:34:09
ワイルドカードはいらなかった

392:デフォルトの名無しさん
09/01/10 14:35:37
ジェネリクスをイレージャタイプにしてしまったのは拙速だったとはいわれてるね。

393:デフォルトの名無しさん
09/01/10 15:24:14
VMの互換性の重視と
必要ないって意見に配慮して穏健なものにしたからだろうね。

394:デフォルトの名無しさん
09/01/10 16:28:34
GenericsはC++のテンプレートと全く違うんだけど？
違いが分からないなら使わない方がいいよ。どうせ「長くて可読性が」どうとかこうとかなんでしょ

395:デフォルトの名無しさん
09/01/10 16:44:00
ランタイムサポートされたGenericsの世界を知らないの?
C#なら型やメソッドを型パラメータごとに動的生成したりnew T()とかできるんだぜ

396:デフォルトの名無しさん
09/01/10 16:57:07
Mbeanをもっと作りやすくしろ

397:デフォルトの名無しさん
09/01/10 17:06:06
>>394
なに頓珍漢なこと言ってるんだ。
イレージャタイプって意味も分かってないのか。

398:デフォルトの名無しさん
09/01/10 17:24:44
Googleで検索しても実質0件だがなあ

399:デフォルトの名無しさん
09/01/10 18:11:20
『「実質0件」でぐぐって50件くらいしかないから「実質0件」という日本語はあまり使われていない』
というのと似たようなものだな

400:デフォルトの名無しさん
09/01/10 18:12:10
ググっても意味がわかんなかったといっておる

401:デフォルトの名無しさん
09/01/10 18:17:33
英語分からない人は、こういうこと知る機会は制限されてるでしょ。

402:デフォルトの名無しさん
09/01/10 18:22:15
Type Erasure（型消去)ってことね
イレージャタイプじゃでてこんわね

403:デフォルトの名無しさん
09/01/10 19:04:53
>>397
それなら、イレージャタイプから消えた方情報（クラスなど）を動的に知る方法を教えてくれませんか？

404:デフォルトの名無しさん
09/01/10 19:10:18
erasure形式っていうことじゃねぇの？

405:デフォルトの名無しさん
09/01/10 19:11:18
>>403 は子供みたいなこと言ってるし、これは荒れるな

406:デフォルトの名無しさん
09/01/11 00:24:41
互換性との兼ね合いでこうなりました、終了。でいいじゃん。
new T()はできないけど、
T newInstance(Class<T> cls) { return cls.newInstance(); }
で実用上困らないし。

407:デフォルトの名無しさん
09/01/11 00:31:51
>>406
T.classとかできないからそのgenericクラスorメソッドから
そのメソッド呼ぶのが難しい
どこか(大抵はコンストラクタか)でClassオブジェクトもらわんと

408:デフォルトの名無しさん
09/01/11 00:37:56
>>392
Genericsも寸止めあったぞ。拙「速」ではなかった。
しかしすごい残尿感が今でもある。

ゴスリンたちの感覚ではBGAAは過激過ぎるのかもね。
俺はプログラミング言語系のこういう単純なアイデアでは久々に萌えたけども。
Closure invocation syntaxにはさ。

409:デフォルトの名無しさん
09/01/11 01:39:07
リアルで残尿感が・・・寄る年波（泣

はじめはコレクションのキャストがなくなると便利だよねってぐらいだったのに、
モノが出たら途端にあれもこれもって状態になったのは覚えてる。

410:デフォルトの名無しさん
09/01/11 05:03:32
クロージャはそのうち導入されるけどjdk1.7では後続の情報がないから微妙かな。
ただアレだけ斬新なアイディアがたくさん出たから、1.7updateの途中で追加されたり、1.8とかの持ち越されるだけじゃないかと思う。
Generだって未だに良く分かってない人多いし、まだ時期尚早と判断されているのかもしれない。
そうしていると、クロージャある言語js,ruby,schemに人が流れる。ただクロージャのためだけに、C#に行く人はいないだろ。

411:デフォルトの名無しさん
09/01/11 05:20:26
だから、C++のテンプレートとは全く違うっていってんでしょ。
>>405-407

412:デフォルトの名無しさん
09/01/11 05:22:38
クロージャやプロパティや実体を持ったジェネリックがC#にはあるでな

413:デフォルトの名無しさん
09/01/11 05:29:39
>>411
誰がC++と比べてるんだ？

414:デフォルトの名無しさん
09/01/11 08:45:01
>>408
BGGAのGの一つはゴスリンのGだぞ。

415:デフォルトの名無しさん
09/01/11 08:56:34
closureのためにC#に行くのは癪だからjavafxで暫く様子見かな。
/* * save usdkrw.fx
javafxc usdkrw.fx
javafx usdkrw
*/
function getfuncs() {
// 空の関数配列がうまく作れないので要素を１つもつ配列を作ってみた
var i = 0; var rt = [ function() : Void { println("aaa : {i}") } ];
while (++i < 10) {
var j = i; insert function() : Void { println("bbb : {i}, {j}") } into rt
}
for (j in [1..9]) {
i++; insert function() : Void { println("ccc : {i}, {j}") } into rt
}
rt
}
for (f in getfuncs()) f();

416:デフォルトの名無しさん
09/01/11 09:04:11
結局C#でも

delegate(int i){ return i * i; }
この記法では使い物にならなくて

i => i * i
こうなった
クロージャ作るならここまでやらないとダメ

417:デフォルトの名無しさん
09/01/11 09:51:31
>>411
C++のテンプレートとの違いなんて話題になってないよ。
それをいきなりC++のテンプレートと違うなどとわめいても、だれも相手にしない。

418:デフォルトの名無しさん
09/01/11 10:01:17
.NET4.0のように、並列機能を強化して欲しい
あっちはfor loopを自動で並列化してくれるようになるらしいぞ

419:デフォルトの名無しさん
09/01/11 10:14:14
あれは並列化するだけだし
その程度ならクロージャさえあれば簡単に出来る

420:デフォルトの名無しさん
09/01/11 10:25:36
>その程度ならクロージャさえあれば簡単に出来る
本当？
クロージャを知らないJava世代の俺に例を教えてくれ

421:デフォルトの名無しさん
09/01/11 10:29:56
Parallel.For(0, 10000, i =>
{
// 重い処理
});

こうしたら重い処理を並列実行してくれるというだけの機能だから

422:デフォルトの名無しさん
09/01/11 10:29:58
コンパイラいじったり言語仕様拡張していくのはC++で十分。
MSお得意の「拡張・吸収・淘汰」によって技術を食べていっちゃうMSの手口知らないの？
そんなことしていると、そのうちに蛙まで食べちゃう「カオナシ」になっちゃうよｗ

423:デフォルトの名無しさん
09/01/11 11:04:51
>>410
まあクロージャ入るのは間違いないだろうね。BGAAが。
>>409
いまさら実行時サポートなしのやつだけなのか！って驚きの方が大きかったが。
>>417
C++と同じところ(erasure type)が話題になっていたわけだからね。

424:デフォルトの名無しさん
09/01/11 11:13:46
>>420
BGAA提案ならfor文に相当するものをユーザ定義できる。
>>421の{ //重い処理 }に相当するループ変数を引数とするクロージャを、
生成したスレッドに実行させる新しい並列forを定義するだけ。

BGAAがあればそういう構文はいくらでも新しく定義できる。
Lock(ロック変数) { 排他処理; }
InputWith(new 対話ウィンドウ()) { 入力処理 }
など。
デストラクタ相当のコードを埋め込んで、close処理もできる。
しかも例外安全で。

並列forを特別扱いで別個に導入なんてpgr以外の何者でもない。

425:デフォルトの名無しさん
09/01/11 11:15:25
クロージャと通常の処理の外からの見分けが付かないのは
危険極まりないと思うがね

426:デフォルトの名無しさん
09/01/11 11:19:10
BGAA

427:デフォルトの名無しさん
09/01/11 11:19:32
>>425
提案読んだことないのが丸分かりだね。
このスレで意見を書くのはまだ早いのでは？

428:デフォルトの名無しさん
09/01/11 11:32:57
ニューｎファンネルバリアって射撃属性だよね？
だったらスナイプつけて雑魚即死で余裕だぜ！！

429:デフォルトの名無しさん
09/01/11 11:37:38
>>415
つScala。クロージャが欲しいだけでも学ぶ価値あり、と思ってる。
ただ、IDE(つかEclipseのScala Plugin)がヘボいのが難点……。

430:デフォルトの名無しさん
09/01/11 11:40:56
>>427
きみ、ヤバイよｗｗ
バカ丸出しだしｗ

431:デフォルトの名無しさん
09/01/11 11:51:28
Lock lock = new ReentrantLock();
withLock(lock) {
　　System.out.println("Under 'withLock' control.");
}

こんなことが出来ちゃうってのがBGAAだろ
これがぱっと見クロージャを使ってるように全く見えないのが問題だって話だ

432:デフォルトの名無しさん
09/01/11 11:53:21
そんなん問題にしてる奴なんかいない

433:デフォルトの名無しさん
09/01/11 11:56:12
だったら問題にせえよ
演算子オーバーロードも認めないくせに
なんで制御構造の独自定義を認めるんだよ

434:デフォルトの名無しさん
09/01/11 11:59:51
BGAA君

435:デフォルトの名無しさん
09/01/11 12:05:27
演算子オーバロードを認めて何かいいことあんの？ただの構文砂糖なだけじゃないか。ｗ
上にもデリゲート結合+=の例で書いてあるけど、可読性云々はなしよｗ

436:デフォルトの名無しさん
09/01/11 12:10:09
構文糖衣ったって+より*が優先されるメソッドなんて作れんだろ
しかしそれがないと多倍長整数も複素数もまともに作れんのだ

437:デフォルトの名無しさん
09/01/11 12:25:13
BGGAとBGAAとあるの？

438:デフォルトの名無しさん
09/01/11 12:25:33
俺は演算子オーバーロードも欲しい。
C++やHaskellでの例を見ても、
変態的な演算子オーバーロードは決して流行らず廃れていく。
可読性のあるものだけ残っていく。
boost::expressiveみたいなのが主流になることはない。

439:デフォルトの名無しさん
09/01/11 12:29:55
おれよくライブラリとか作るけど、例えば多倍長とかも c=a.sub(b);で実際全く問題なんだが？
たとえば、x=a.sub(b).mul(c)でいいんでないの。
どうせ何も作ったことないで人の言いなりロボット君なんだろうけどｗｗBGAA君もｗｗ

440:デフォルトの名無しさん
09/01/11 12:33:22
可読性

441:デフォルトの名無しさん
09/01/11 12:33:48
>おれよくライブラリとか作るけど

442:デフォルトの名無しさん
09/01/11 12:34:15
ですか（笑）

443:デフォルトの名無しさん
09/01/11 12:36:19
>x=a.sub(b).mul(c)でいいんでないの。

これを見れば分かるように演算子オーバーロードがないと問題があるわけだ
しかしControl Invocation Syntaxはなくても別に困らないわけだ
>>421でも十分使えるからな
むしろクロージャを使っていることを隠してしまうのが問題だ

444:デフォルトの名無しさん
09/01/11 12:38:19
クロージャも算子オーバーロードもないJAVAなんか糞言語。HTTTPだけあれば俺たちは幸せ！

445:デフォルトの名無しさん
09/01/11 12:41:54
そうやってPGの方に宗教的制約を課すなら、そもそも演算子オーバーロードなんか不要でもいいんじゃないの？
JAVAの世界にいる本物のSEや本物の職人ではそういう意見が多いんですわｗRUBYIZMなんかよりもよりも実利的ですなｗｗ

446:デフォルトの名無しさん
09/01/11 13:05:28
表現が全く説得力ないよなあ
意見が多い、か。

447:デフォルトの名無しさん
09/01/11 13:10:34
常に張り付いてる奴もいるし、雑学ばっかり増やしてるひまあったら手を動かせ。
くだらんスレだｗ

448:デフォルトの名無しさん
09/01/11 13:14:35
>>443
おまえの頭はおかしいからな。

449:デフォルトの名無しさん
09/01/11 13:35:17
Control Invocation Syntaxは別にクロージャ使ってること隠してないでしょ
見ればControl Invocation Syntax使ってるのは一目でわかる(=クロージャ
使ってることが一目でわかる)んだから。なんつーか、BGGAの提案書まともに
読んだこと無いやつが多過ぎだよ

450:デフォルトの名無しさん
09/01/11 13:37:24
あと、クロージャとか関数型の便利さを知りたいならScalaやってみると良いよ
基本的に言語仕様のほとんどの部分でScalaの方が優れてるし(制御構造に
関しては一部劣化してるが)

451:デフォルトの名無しさん
09/01/11 13:40:23
>>449-450
創価学会ってそんなにいいところなんですか？
みんな笑顔で楽しそうなんですけど・・・

452:デフォルトの名無しさん
09/01/11 13:41:18
>>450
何が優れてるって？ｗ

453:デフォルトの名無しさん
09/01/11 13:46:34
確かにScalaの言語仕様はJavaみたいなウンコのはるか高みにあるね

454:デフォルトの名無しさん
09/01/11 14:10:27
>>453
それでウンコの上で馴れ合って楽しいんですか？

455:デフォルトの名無しさん
09/01/11 14:12:31
俺はJavaの後進性をあげつらって楽しんでるだけだよ

456:デフォルトの名無しさん
09/01/11 14:32:39
学会さんですもんね

457:デフォルトの名無しさん
09/01/11 14:33:36
あの・・・・BGAAってなんですか？

458:デフォルトの名無しさん
09/01/11 14:37:36
ほんとなんなんだろうな

459:デフォルトの名無しさん
09/01/11 17:28:53
Java6があまり進化しなかった代わりにJava7は大幅に進化するって聞いてたんですけど、
どの辺がすごくなるんですか！？

460:デフォルトの名無しさん
09/01/11 17:37:37
すごくなる予定はありません

461:デフォルトの名無しさん
09/01/11 17:46:14
>>450
まぁそういうの必要な人はScalaとか使うのが正解だよな。
わざわざJavaに追加する必要もない。

462:デフォルトの名無しさん
09/01/11 19:53:57
>>461
確かにJavaに追加する必要があるかは議論の余地があるけど
クロージャのある言語をろくに使ってみたことも無いやつが良し悪し
についてまともな議論できるものかねえ。

463:デフォルトの名無しさん
09/01/11 20:01:36
クロージャがあると

string[] fruits = new [] {"apple", "banana", "orange"};
bool flg = false;
foreach(string fruit in fruits) {
　if (textBox.Text.Contains(fruit)){
　　MessageBox.Show(fruit + "です。");
　　flg = true;
　　break;
　}
}
if (!flg) {MessageBox.Show("一致しません。");}

これが

var result = fruits.FirstOrDefault(fruit => textBox.Text.Contains(fruit));
if(result != null)
MessageBox.Show(result + "です。");
else
MessageBox.Show("一致しません。");

こうなるんだぜ

464:デフォルトの名無しさん
09/01/11 20:14:28
VB?何か汚いなあ

465:デフォルトの名無しさん
09/01/11 20:15:45
逆にクロージャいれると何か困ることある？
便利そうなのはなんとなく分かったけど。

466:デフォルトの名無しさん
09/01/11 20:22:17
クロージャ使ってるソースコードが
慣れないと読みにくいというのがあるかな

467:デフォルトの名無しさん
09/01/11 20:24:11
慣れてなくても読みやすいものなんて

468:デフォルトの名無しさん
09/01/11 20:28:02
Javaに入るとして、クロージャの引数は型宣言無しで使えるのでしょうか。
クロージャが入ってくると高階関数を使いたくなるのは自然だと思いますが
（それがないならコレクションに対するシンタックスシュガー程度にしかならない）
型推論のサポートが無いままJavaに突っ込まれても、ちょっとマゾいんじゃないかと思います。

469:デフォルトの名無しさん
09/01/11 20:34:37
クロージャ入れた後で型推論付き（引数の型宣言なし）もできるようにするのは
そんなに難しくないから、とりあえず型推論なしで入れちゃってもOKだと思うぞ。

470:デフォルトの名無しさん
09/01/11 20:39:06
いや無理でしょう。やはりJavaには馴染まない気がします

471:デフォルトの名無しさん
09/01/11 20:39:15
>>463
FirstOrDefaultの定義は？
それが汎用的に書けるのが利点だというのはわかるんだけどさ。

472:デフォルトの名無しさん
09/01/11 20:46:37
というか型推論がないとコレクションに対するシンタックスシュガーとして
すら使いたくないなぁ。面倒くさくて。
というわけで型推論もクロージャも欲しいです。ものぐさとしては。

473:デフォルトの名無しさん
09/01/11 20:51:03
ですね。
でも型推論を入れてしまうと、クロージャに限らない話になってしまって
（少なくとも見た目的には）もうJavaがJavaでなくなるような雰囲気があります。
だから馴染まないと書きました。

474:デフォルトの名無しさん
09/01/11 21:06:48
>>471
LINQというライブラリにあるんだけど

public static T FirstOrDefault<T>(this IEnumerable<T> e, Func<T, bool> pred)
{
　foreach(T item in e){
　　if( pred(item) )
　　　return item;
}
return default(T);
}

こういうものだな
thisというのはstaticメソッドをその引数のインスタンスメソッドのようにして呼び出す記法

475:デフォルトの名無しさん
09/01/11 21:27:10
Javaなら素直にこんな風に書けばいいと思いますが駄目ですかね。

String[] fruits = { "apple", "banana", "orange" };
String result = firstMatched(text, fruits);
if (result != null) {
　MessageBox.Show(result + "です。");
} else {
　MessageBox.Show("一致しません。");
}

int firstMatched(String text, String[] fruits) {
　for (String fruit : fruits) {
　　if (text.indexOf(fruit) != -1) {
　　　return fruit;
　　}
　}
　return null;
}

text.indexOf(fruit) != -1 の部分を汎用的にしたければ
Predicateクラスでも作って引数に渡せばいいんじゃない？
…というのが「Java流」だと思うのですが。

476:デフォルトの名無しさん
09/01/11 21:27:55
手が滑った。firstMatchedの戻り値はStringに読みかえて下さい

477:デフォルトの名無しさん
09/01/11 21:39:33
Predicateクラス作れったってめんどくさくて誰もやらないでしょう
関数に分けるより直接書いちゃったほうがコードもむしろ読みやすい気がする

478:デフォルトの名無しさん
09/01/11 21:43:05
Predicateクラスでも作って引数に渡すのがJava流というのはその通りだと思うし
Google Collections Libraryでも実際にそんな感じのクラスがあったりするけど
いちいち必要になるたびに別個にクラス作らなきゃならんのがダサい
無名クラス使えば記述量は多少減らせるけど煩雑だしな

479:デフォルトの名無しさん
09/01/11 21:44:43
いや、そういうの(Predicateクラス作れ)をめんどくさいという人
(or そういうのがめんどくさいと感じる規模のプログラム)なら
Javaで書こうとするのが間違ってる。

スクリプト言語とはニーズが違うと思うんですよ。
小さいプログラムを光速で書き上げるところに明確なニーズのある言語なら、
クロージャでも何でも「便利だから」の一点で正当化されると思うんですが、
Javaってそういう言語じゃないでしょう。

480:デフォルトの名無しさん
09/01/11 21:46:57
いやいや、小さいプログラムに限った話じゃないし、スクリプト言語関係無いから
クロージャ＝スクリプト言語由来の機能だとでも思ってる？

481:デフォルトの名無しさん
09/01/11 21:49:24
関数型言語由来の機能ですよ。

closure = environment + function
object = state + function

482:デフォルトの名無しさん
09/01/11 21:59:44
DBにアクセスして結果をブラウザに返すだけのプログラムしか作ってないんだろ？
クロージャとかホントにいるの？

483:デフォルトの名無しさん
09/01/11 22:05:27
Predicateクラスの中で必要なのは条件のメソッドの中身だけで
他の部分はノイズでしょう

しっかりクラスを作ってノイズをたくさん増やしたところでプログラムが堅牢になるわけじゃなく
ノイズによって可読性が下がっては本末転倒なわけです

FirstOrDefaultのような抽象化は現状のJavaの言語機能では現実的じゃないし
だからといってコレクションに対する定型的な処理を毎回手で書くのもバグの元

すばやく書けるかも大事だけど
可読性が高くバグが入りにくいプログラムを書くには
どういう言語機能が必要かという視点で考えていかないと

484:デフォルトの名無しさん
09/01/11 22:06:55
クロージャいらね。

485:デフォルトの名無しさん
09/01/11 22:11:32
関数型とかわけわかんねえものは要らねえよな。
プログラミングは数学じゃねえぞ。

486:デフォルトの名無しさん
09/01/11 22:14:15
>>483
>FirstOrDefaultのような抽象化は現状のJavaの言語機能では現実的じゃないし
>だからといってコレクションに対する定型的な処理を毎回手で書くのもバグの元

いやいや、論点はそこじゃなくて…

>public static T FirstOrDefault<T>(this IEnumerable<T> e, Func<T, bool> pred)

この Func クラスのインスタンスを生成する構文を言語仕様として導入することの是非、では？

487:デフォルトの名無しさん
09/01/11 22:18:50
具体的に補足。

>var result = fruits.FirstOrDefault(fruit => textBox.Text.Contains(fruit));

FirstOrDefaultメソッドに渡すpred引数の生成を、上のように書けるところが「凄い」んだけど、
(textBoxが自由変数なので、無名クラス定義の単純な構文糖とは違う)
その凄さがJavaに必要かどうかでしょう。

488:デフォルトの名無しさん
09/01/11 22:28:31
必要かはともかく、欲しい。

489:デフォルトの名無しさん
09/01/11 22:29:07
そういった機能を言語仕様に導入しないと
毎回手で書いた方がマシな状態になってしまうのだから
Javaにもその機能が必要でしょうよ

490:デフォルトの名無しさん
09/01/11 22:34:57
CがC++になったときみたいな論争だね。

491:デフォルトの名無しさん
09/01/11 22:43:47
>>485
数学的な素養がなくて抽象化もできないお前みたいなやつ
ばっかりだから、ＩＴ業界がデジタル土方って言われるんだよ。

492:デフォルトの名無しさん
09/01/11 22:47:05
今言えるのは、このスレみたいな状況下でクロージャぶち込んでも混乱するだけ。
プログラマーが苦労するか楽するかだけの問題ならね。

493:デフォルトの名無しさん
09/01/11 22:55:08
>>492
>このスレみたいな状況下で

２ちゃんねるを基準されても…

494:デフォルトの名無しさん
09/01/11 22:55:27
>>491
Javaはドカタ用の言語だろ？
ドカタじゃないならHaskellでもMLでも使っとけ

495:デフォルトの名無しさん
09/01/11 23:01:29
クロージャ使うとこんな感じで書くの？
int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
System.out.println(numbers.sum());

public static int sum(this IEnumerable<int> e) {
　return numbers.fold(s => i => s + i, 0);
}

public static R fold(Func<R,Func<T,R>> f, R s, this IEnumerable<T> e) {
　R result = s;
　foreach (T item in e) {
　　result = f(result)(item);
　}
　return result;
}

496:デフォルトの名無しさん
09/01/11 23:01:38
楽に書けるようになれば土方だって幸せ。
通もうなる屁理屈と土方だって使える簡潔さ、両者を満たすのが理想。

497:デフォルトの名無しさん
09/01/11 23:05:36
というかfoldとかFirstOrDefaultがstatic関数として宣言されているのはどうして？
お馬鹿さんにも分かりやすいように教えて下さい。クロージャの扱いと関係ある？

498:デフォルトの名無しさん
09/01/11 23:07:41
関係ない

499:デフォルトの名無しさん
09/01/11 23:08:19
土方としてはクロージャよりBigDecimalで演算子使える方がうれしい
Java案件の多く(金額ベース)は金融なんだからよろしく頼むよ

500:デフォルトの名無しさん
09/01/11 23:11:32
>>499
泣いた。
演算子の再定義が無い事が今更ながら非人道的だと思えた。

501:デフォルトの名無しさん
09/01/11 23:15:06
つーかたかがクロージャ一つが要る要らないなんて話になる時点でどうかと思うんだけどね。
そんなにジェネリクスもクロージャも嫌なら、SUNに金出してずっとJDK1.4のサポートしろとでもごねるか、
JDK1.4相当のフリーの実装でもかっぱらってきて自社でサポートするかすればいいのに。
技術もない金も出したくないサポートもしたくない自社で責任持ちたくないドカタ以外使えない使いたくないだけどJavaコミュニティは俺らの要求にしたがって俺ら好みの実装をサポートし続けろってなにそれw

502:デフォルトの名無しさん
09/01/11 23:17:06
こんばんは、今宵もFX厨が通りますよ

def　fruits　=　[　"apple",　"banana",　"orange"　];
var　inputtext　=　"apple";
var　msg　=　"";
　:　
SwingTextField　{　text:　bind　inputtext　with　inverse,　editable:　true　}
SwingButton　{
　　action:　function()　{
　　　　　var　hits　=　fruits[s　|　s　==　inputtext];
　　　　　msg　=　{　if　(sizeof　hits　==　0)　"unmatch"　else　"match　{hits[0]}"　}
　　}
}
Text　{　x:　0,　y:　20,　content:　bind　msg　}
　:

503:デフォルトの名無しさん
09/01/11 23:17:29
ドカタとしてはControl Invocation SyntaxでRAIIできれば幸せ。

504:デフォルトの名無しさん
09/01/11 23:18:44
なんでもいいけど、コンパイルが通った後でtype mismatchとかいう例外が起きる言語は使い物にならないよ

505:デフォルトの名無しさん
09/01/11 23:20:34
>>504
それはつまりキャストのある言語(Java含む)は使い物にならないってことかね？

506:デフォルトの名無しさん
09/01/11 23:21:23
例外なしでいきなり逝く方が良いと

507:デフォルトの名無しさん
09/01/11 23:21:31
ジェネリクスがあるのに好き好んでダウンキャストする馬鹿なんてまだいるの？

508:デフォルトの名無しさん
09/01/11 23:22:21
>>495
それでいいと思うけど
LINQだと(s,i) => s + i と書くけどな

509:デフォルトの名無しさん
09/01/11 23:26:01
｛引数型リスト、返り値型、例外型リスト｝を全部まとめたものがクロージャの型宣言になって
やっぱりJavaだと型宣言を省略させるわけにはいかないから結構だるそうですね

510:デフォルトの名無しさん
09/01/11 23:30:39
そりゃ関数型の方でしょ。
クロージャなら戻り値型や例外型は型推論できるし
代入先の情報がありゃ引数型も型推論できる。

511:デフォルトの名無しさん
09/01/11 23:32:32
Control Invocation Syntaxって値返せないんでしょ
そんなあまり使い道のないケースを言語として特別扱いするのは
筋が悪い気がするよ

512:デフォルトの名無しさん
09/01/11 23:33:15
>>510
そもそもBGGAだと戻り値型と例外型は型推論してるしな

513:デフォルトの名無しさん
09/01/11 23:33:49
>>507
好き好んでダウンキャストはしないが、ライブラリ(Javaの標準ライブラリ含む)の都合で
ダウンキャストが避けられない場面はある。それよりも、上で言ってるのは言語の話
であってキャストをユーザが使うかどうかという話じゃないんだがな

514:デフォルトの名無しさん
09/01/11 23:35:57
>>511
値返せたほうが便利だけど値返せなくても十分使い道はあるよ。

515:デフォルトの名無しさん
09/01/11 23:36:17
>>511
クロージャはともかくControl Invocation Syntaxは必要かどうかは微妙なところ
だけど、Control Invocation Syntax無いと言語のファーストクラスの制御構造
(forやwhile)と同等のものが作れないからなー(breakとかcontinueなどが使えない
ので)。

516:デフォルトの名無しさん
09/01/11 23:41:50
>>510
>>代入先の情報がありゃ引数型も型推論できる。

これ重要だ。クロージャを受領する側では型定義を明示的に宣言させる
必要があるけど、実際にクロージャを作って投げつける側ではガンガン
型推論やってシンプルに書ける方がよい。

苦労はなるべくライブラリを作成する人に押しつける方向で。

517:デフォルトの名無しさん
09/01/11 23:44:21
クロージャの引数型の推論はC# 3.0でもScalaでもやってるし
Javaでもやってできないことは無いだろう。型システム上、
完全な推論は難しいと思うけど、ほとんどのケースでうまく推論できると思う

518:デフォルトの名無しさん
09/01/11 23:45:44
>>511
クロージャを引数に取って値返すメソッド書くのは自由だよ。

519:デフォルトの名無しさん
09/01/11 23:49:01
>>510
URLﾘﾝｸ(www.javac.info)
これを読んで、あなたが何を言ってるのか理解しました。

たとえばこれで言えば
{int=>int} plus2 = {int x => x+2};

右辺をクロージャと言って左辺を関数型と言っているわけですね。
私の>>509では、この左辺の{int=>int}をクロージャの型といいました。
結局この部分は何も省略できないですよね。

520:デフォルトの名無しさん
09/01/11 23:49:46
>>518
Control Invocation Syntaxは扱い上、「文」だから値返せねえという話でしょ
>>511はクロージャだけあれば十分でControl Invocation Syntaxというシンタックスシュガー
は要らんという意見だと思う

521:デフォルトの名無しさん
09/01/12 06:28:45
なんかあれだな。１年前のクロージャ議論（英語）を見てるようだ。
プロトタイプ実装がダウンロードできるから使ってみるといい。
JAVAクロージャを使ったこともないのに理想であれこれ言う奴が多いから、まだPGの間で導入するかの合意が取れてなってないってのが動流が微妙な理由なのよ。1.7までまだ１年以上あるけど。

それよりも、C#でコード書くともう既に意味不明になってるな。
関数引数の中のthisとかなによ？ｗｗLINTとかドカタ用だしグチャグチャじゃんｗｗｗ
そういうのはVC＋＋だけでやれって。C#をMSBASICみたく汚さんでくれ。（もう遅いけど）
こうやってみるとJAVAは言語仕様の拡張は自然だし安心できる。

522:デフォルトの名無しさん
09/01/12 09:05:12
関数引数の中のthisは
「インターフェースに実装を持ったインスタンスメソッドを定義する」ためのやり方だな
コレクション一般に対してクロージャを適用するメソッドを書くためには
こういった機能が必要になる

30歳以上の給料の平均を
persons.filter({ Person p => p.Age >= 30 })
　　　　　.map({ Person p => p.Salary })
.average();

こう書けるようにするものだ
これがないと

average(
　　map(
　　　filter(persons, { Person p => p.Age >= 30 }),
{ Person p => p.Salary })))

こうなったり

Iterable<Person>
　result = filter(persons, { Person p => p.Age >= 30 })
　result = map(result, { Person p => p.Salary })
int ave = average(result);

こうなったりする。C#だと正確には

persons.Where(p => p.Age >= 30)
　　　　　.Select(p => p.Salary)
.Average();

こうだけどな

523:デフォルトの名無しさん
09/01/12 09:10:08
やり直し

30歳以上の給料の平均を
persons.filter({ Person p => p.Age >= 30 })
　　　　　.map({ Person p => p.Salary })
　　　　　.average();

こう書けるようにするものだ
これがないと

average(
　map(
　　filter(persons, { Person p => p.Age >= 30 }),
　　{ Person p => p.Salary })))

こうなったり

Iterable<Person>
　result = filter(persons, { Person p => p.Age >= 30 })
　result = map(result, { Person p => p.Salary })
double ave = average(result);

こうなったりする。C#だと正確には

persons.Where(p => p.Age >= 30)
　　　　　.Select(p => p.Salary)
　　　　　.Average();

こうだけどな

524:デフォルトの名無しさん
09/01/12 10:19:16
それって多重継承の問題が出てくると思うけど名前空間はどうやって解決してるの？

525:デフォルトの名無しさん
09/01/12 10:47:01
.NET のクロージャは LINQ のためにあると言っても過言ではないだろう。

「DTO のコレクションに対する操作」を簡潔に記述するための便利シンタックス
として利用するにとどめるのが「.NET 流」であって、クロージャクロージャと
大騒ぎして関数型言語風のプログラムを書き始めるのは、
むしろプログラマとして致命的にセンスがないと思うがどうか。

526:デフォルトの名無しさん
09/01/12 10:53:44
>>524
こんな風に定義するわけだけど

public static class StaticClass1
{
　public static void Method(this Interface1 i1){}
}

public static class StaticClass2
{
public static void Method(this Interface2 i2){}
}

基本的には名前がかぶると呼び出せない

public class Class : Interface1, Interface2{}

Class c = new Class();
c.Method(); //これは呼び出せない

代わりに
StaticClass1.Method(c);
StaticClass2.Method(c);
スタティックメソッドとして呼び出す

527:デフォルトの名無しさん
09/01/12 11:04:37
そんなにC＃が好きならC＃でやれよ。
いつのまにか君もMS信者になっちまっちゃってるのかも。

528:デフォルトの名無しさん
09/01/12 11:07:45
ん、なんかこのスレにアンチMSが紛れ込んでるぞ

529:デフォルトの名無しさん
09/01/12 11:18:26
>>523
> average(
> 　map(
> 　　filter(persons, { Person p => p.Age >= 30 }),
> 　　{ Person p => p.Salary })))
>
> こうなったり

average(map(filter(persons,
　　　　　　　　　　　{ Person p => p.Age >= 30 }),
　　　　　　　{ Person p => p.Salary })))

わざと見にくくしてないのなら、こうインデントしてくれ

530:デフォルトの名無しさん
09/01/12 11:18:55
Javaスレで違う言語の話ばかり延々とされてもな

531:デフォルトの名無しさん
09/01/12 11:24:18
じゃあC#の話は禁止で。

532:デフォルトの名無しさん
09/01/12 11:34:56
>>525
大騒ぎするもんでもないが、「DTOのコレクションに対する操作」を簡潔に記述するための
便利シンタックスとしてしかとらえられてないんだったら見方が狭いとしか言いようが無いな
あと、.NETのクロージャがLINQのためにあると言うけど、それだけではないでしょ
クロージャ自体はLINQが入るはるか前の.NET 2.0からあるんだし。

533:デフォルトの名無しさん
09/01/12 11:41:55
↑Javaと関係ないからレス禁止な

534:デフォルトの名無しさん
09/01/12 11:42:40
LINQのために追加されたのはラムダ式だな

535:デフォルトの名無しさん
09/01/12 11:49:54
ボクシングやアノテーションなんてのはC#の後追いなわけだし
プロパティもクロージャも後追いなわけで
Javaに追加する言語仕様の話をするならC#の話は避けて通れないだろ

536:デフォルトの名無しさん
09/01/12 11:53:35
お前Javaに追加する言語仕様の話は一切してなくてC#の言語仕様の紹介しかしてないだろ
だからスレ違いだっつーの

537:デフォルトの名無しさん
09/01/12 11:59:06
>>535
後追いっつうのはちと語弊があるな。別にクロージャはC#の専売特許でもなんでもない
そもそも関数型言語由来の機能だし。あと、BGGAのクロージャは、C#のそれとはかなり
違うものだから。

538:デフォルトの名無しさん
09/01/12 12:02:00
話をJavaのクロージャに戻すと、Control Invocation Syntaxは結構便利だと
思うけどなー。サンプル版使ってみたけど、これ使うの前提でIO関係のライブラリ
作ればこれまで面倒だった処理がかなりすっきり書けるよ。

539:デフォルトの名無しさん
09/01/12 12:07:42
Control Invocation Syntax使うために標準ライブラリを書き直すつもりなの？

540:デフォルトの名無しさん
09/01/12 12:10:07
>>535
ボクシングは関数型言語の後追いですね。
そのためにSPJがMSRに呼ばれました。

541:デフォルトの名無しさん
09/01/12 12:11:48
IO関連だけならライブラリ書き直す必要ないし。
コレクションでLINQ的な使い方するなら拡張メソッド導入するか
標準ライブラリ書き直しかする必要あるけど。

542:デフォルトの名無しさん
09/01/12 12:54:34
冷静に考えると、
ボクシング、アンボクシングは心底いらないと思う

543:デフォルトの名無しさん
09/01/12 13:06:39
URLﾘﾝｸ(journal.mycom.co.jp)
ここにあるような自動クローズ機能を持つwith文だと
try {
String text = "";
BufferedReader reader =
new BufferedReader(new FileReader("in.txt"));

with(BufferedReader in : reader) {
text = in.readLine();
}
} catch(IOException ex) {
ex.printStackTrace();
}

結局withし忘れたらどうするんだという話になるでしょう
理想を言うと

try{
File file = new File("in.txt");
openRead( BufferedReader reader : file){ ...(ファイルを処理) }); //自動クローズ
}catch...

openを呼び出した時に渡すクロージャからしかアクセスできなくしたいじゃない

544:デフォルトの名無しさん
09/01/12 13:06:48
クロージャは導入されるから安心しろ。問題はそれがいつになるかだけ。
それと、専売特許以前に、C＃とJAVAを比較しても全く意味ない。もともとC#（.Net)がJava/JVMのマネでしょｗ

545:デフォルトの名無しさん
09/01/12 13:18:37
比較しても意味ない？
なんでそんな非科学的なの？
後を追ってる言語が先を行ってる言語を参考にするのは当たり前のことだろ
Javaはもはや後進言語だってことを認識しなさい

546:デフォルトの名無しさん
09/01/12 13:22:43
後進でいいよ。
下手に先進的な機能つけて失敗された方がかなわん。

547:デフォルトの名無しさん
09/01/12 13:34:49
>>546
MFCのことを侮辱するのはいい加減にしてください。

548:デフォルトの名無しさん
09/01/12 13:35:55
ん、なんかこのスレにMS信者が紛れ込んでるぞ

549:デフォルトの名無しさん
09/01/12 14:15:05
大きな改変がないんなら、リリースやめてもらったほうが1.4延命できていいんだが

550:デフォルトの名無しさん
09/01/12 14:32:43
>>549
既に死んでるじゃん、1.4。

551:デフォルトの名無しさん
09/01/12 14:56:57
JavaとC#が互いにどっちが先進的だとか何とか、アホかと
closureなんてsmalltalkにだってあるだろ

552:デフォルトの名無しさん
09/01/12 15:05:07
>>551
土方言語限定の井戸端会議ですから。

553:デフォルトの名無しさん
09/01/12 15:13:17
クロージャなんぞLispからあるわ
じゃあ今のJavaが目指してるのはLispか？違うだろ
Javaは今C#を目指してるんだよ

554:デフォルトの名無しさん
09/01/12 15:15:49
今となってはMFCのためにMSに金払って買ってたのがバカらしい

555:デフォルトの名無しさん
09/01/12 15:16:49
たぶんControl Invocation SyntaxもC#に先に入ると思いますw
javac.infoの中の人、MS行っちゃったし。

556:デフォルトの名無しさん
09/01/12 15:20:29
C#で実験してくれるならそれもいい。

557:デフォルトの名無しさん
09/01/12 15:21:19
Apache+Tomcatの構成が廃れない限りC#はJavaに勝てないと思う

558:デフォルトの名無しさん
09/01/12 15:27:35
MSにとってどういう扱いなのか知らないが、Javaにとっては完全にC#は実験台だよね。
C#がどんどん仕様追加して、美味しい（問題がなさそうな）とこだけJavaが頂戴する。

559:デフォルトの名無しさん
09/01/12 15:30:38
正直MSの方向性は謎

企業としては利益を追求しすぎでコミュニティにそっぽを向かれ
そのくせ、出てくる製品は先進的すぎて企業にはそっぽを向かれ

何を狙ってるのかさっぱりわからん

560:デフォルトの名無しさん
09/01/12 15:35:53
先駆者である必要はない
より使えるものになればそれでいい
使えなくなれば他を使えば済むだけ
道具のひとつと一緒に心中するなんてやつはいないだろ

561:デフォルトの名無しさん
09/01/12 15:42:42
誰にとって使えるものになってなきゃいけないかって視点だな
JavaやC#みたいな言語はドカタに使ってもらえなきゃ意味がないわけで
最近のMSはその辺り勘違いしている気がするな

562:デフォルトの名無しさん
09/01/12 15:51:44
おまいらマ板ネタになると俄然元気になるな

563:デフォルトの名無しさん
09/01/12 15:55:04
プログラマ以外Javaなんて使わないだろ

564:デフォルトの名無しさん
09/01/12 16:10:32
無名内部クラスとか
基本型が使えないジェネリックとか失敗だし
何よりブサイクでしょう
オートボクシングもボクシングを推奨してるみたいになって最悪

で、今度は引数の型が省略できないクロージャだよ
Javaの委員会っていうのは変態の集まりなの？
ブサイクなのが大好きなの？

565:デフォルトの名無しさん
09/01/12 16:11:31
オープンソースの台頭によりSUNが死滅してJava健全化。
喜んだのもつかの間、旗振り役がいなくなってJava死滅。
今後の予定です。

566:デフォルトの名無しさん
09/01/12 16:22:01
基本型をジェネリックに使うのはerasureでは無理だからな
C++みたいにコンパイル時に作るか，C#みたいに特殊化したコードを実行時に生成するかしないといけない

567:デフォルトの名無しさん
09/01/12 16:32:29
次のVM仕様で実行時タイプサポートが強くなるから、
もしかしたらGenericsでの基本型の扱いも変わるかもしれない。
今のVM仕様のままだと、他の言語で不便だから。

568:デフォルトの名無しさん
09/01/12 16:40:35
＞基本型が使えないジェネリックとか失敗だし

やばい黒柳徹子が頭から離れない

569:デフォルトの名無しさん
09/01/12 16:47:23
age棒はやっぱりというかMS狂信者なわけで・・・

570:デフォルトの名無しさん
09/01/12 17:33:41
genericsが基本型に対応したらT extends Object//基本型はダメ
が出てくるのかなw

571:デフォルトの名無しさん
09/01/12 23:01:14
Javaはもともと、委員会症候群により仕様が肥大化したC++への
アンチテーゼみたいな矜持があったように思うけどねぇ。
それで逆にJavaBeansやannotationなんかは、構文の拡張を
しないがためにかなり無理のある仕様になってしまったくらいだし。

いつからこうなったのか知らんが、このまま「書くのが楽なら何でもあり」な
Perlみたいになっていくのかね。

572:デフォルトの名無しさん
09/01/12 23:11:15
楽は目指してないような

573:デフォルトの名無しさん
09/01/12 23:16:22
JavaBeansを言語仕様に組み込んだところで（プロパティとか）、コンパイラが複雑になるだけだし変わらん。
Cがなぜ普及したかは、全ての言語機能をライブラリにしたからじゃなかったか？そういうの知らないで育ったゆとり世代なのか。ｗ

574:デフォルトの名無しさん
09/01/12 23:16:40
長い上にロジックが変。
悪いプログラムの見本のようなレス。

575:デフォルトの名無しさん
09/01/12 23:18:11
全ての言語機能だって？
ライブラリしか残らんじゃないか！
この世の終わりじゃ！

576:デフォルトの名無しさん
09/01/12 23:52:08
>>572
んでも、少なくともここでクロージャを欲している人はそういう意見なんじゃね？
その程度でいちいちクラスを起こすのは面倒いって。

577:デフォルトの名無しさん
09/01/13 00:07:59
面倒もあるけど、限られた言語機能の使い回しに伴うノイズが多すぎる。
特に匿名インナークラス。

578:デフォルトの名無しさん
09/01/13 00:17:09
一言で楽したいって言っても人によってイロイロあるからな
例えば楽したくても演算子オーバーロードは絶対駄目な人もいれば
BigDecimal特別扱いでいいからつけてよって人もいるし
インデクサ程度ならって人もいるし
制限なしの演算子オーバーロード欲しいって人もいる

579:デフォルトの名無しさん
09/01/13 07:33:18
後から読む人が犠牲になるような書き易さは害悪

580:デフォルトの名無しさん
09/01/13 08:57:27
Control Invocation Syntaxはライブラリの乱立を招きかねないという懸念があるよね

581:デフォルトの名無しさん
09/01/13 09:06:44
今だってじゅうぶん乱立しとるがな

582:デフォルトの名無しさん
09/01/13 09:13:54
乱立が必ずしも悪いとは思わんけどね
ライブラリ間で競争するだろうし

583:デフォルトの名無しさん
09/01/13 09:27:10
Control Invocation Syntaxあると、なんでライブラリ乱立するの？

584:デフォルトの名無しさん
09/01/13 09:51:45
あるとこでは自動クローズ構文がwithで
別のとこではusing, withは別の構文で使われてるみたいなことになるかもしれない

585:デフォルトの名無しさん
09/01/13 10:02:49
MSのVJ++のデレゲートは叩いたのになんでいまさらクロージャ？

586:デフォルトの名無しさん
09/01/13 10:42:10
>>584
標準ライブラリでもバイト配列への変換が getBytes だったり toByteArray だったりするわけで、
その程度なら乱立しなくても標準ライブラリ内で不統一って事もありうる

587:デフォルトの名無しさん
09/01/13 10:42:46
>>584
そんなのクラス名、メソッド名も同じじゃんw
>>585
JCPでやってることと、一企業の独善的な拡張は違うよ。

588:デフォルトの名無しさん
09/01/13 10:43:52
クロージャとVJ++のデレゲートは別モノだろ

589:デフォルトの名無しさん
09/01/13 10:59:55
>>588 kwsk

590:デフォルトの名無しさん
09/01/13 11:21:34
クロージャと同じなのはC#の匿名デリゲートだろ
VJ++のは関数オブジェクトじゃなくてメソッドポインタだし

591:デフォルトの名無しさん
09/01/13 11:25:12
javaのはなしから脱線してすまないが流れ上説明するよ。
delegateがクロージャとしての機能を持ったのはC#2.0(.NET2.0)からで
VJ++のdelegateはC#1.0のそれと同じで動的にも静的にもスコープは持たない。
安全な関数ポインタというだけのものだった。

そうえばjavaのクロージャは既存のメソッドとの互換は
あんまり考えてないように思えるけどどうなんだろ。
たとえば　int　hoge(int　i)　{　}　と　void　func({int　=>　int}　f)　{　}　があって
func(hoge)　といった書き方ができないよね？

592:デフォルトの名無しさん
09/01/13 12:02:33
関数ポインタとメソッドポインタは全然違うわけだよ
メソッドポインタを関数ポインタで無理やり書けば

Result Method(void* obj, Arg arg1,...)
objの部分を型安全にしたのがメソッドポインタで、
objに処理に必要な変数を自動で入れてくれるのがクロージャ

593:デフォルトの名無しさん
09/01/13 12:14:50
VBやりすぎると頭おかしくなるって言うけど、C＃もやるすぎると頭おかしくなっちゃうんだね

次ページ