08/03/02 22:00:49
>>351はアホだね。
358:デフォルトの名無しさん
08/03/02 22:41:20
おいおい、ほかの言語にももっと目を向けろよ。
Not Nullにする構文がどんだけ有益なことかわからんのか。
359:デフォルトの名無しさん
08/03/02 22:43:26
>>358
せまい世界の問題に何を必死になってんだか
360:デフォルトの名無しさん
08/03/02 23:13:24
じゃあJavaは今のままで問題ないとでも？
361:デフォルトの名無しさん
08/03/02 23:14:41
>>325
362:デフォルトの名無しさん
08/03/02 23:50:07
ぬるぽ
363:デフォルトの名無しさん
08/03/03 04:32:20
そんな考えだから衰退していくんだ
364:デフォルトの名無しさん
08/03/03 04:42:11
だからこんなところで発案するだけ無駄だと言ったろう。
お上から落ちてきた仕様書の解釈論程度の能力しかない下請け連中が集まってるだけなんだから。
365:デフォルトの名無しさん
08/03/03 06:41:33
>>363
というかおまえはJavaa使うな。
おまえはJavaaで何が作れて、Javaaに何期待してるんだ？
吠えてるだけで何も作れない奴はこのあたりで黙っちゃうだがなｗｗｗん？
366:デフォルトの名無しさん
08/03/03 07:29:46
それが良いアイデアだと妄信してる時点で終わってるでしょ
見た目をちょっと変えるだけで何の革新でもないし、
コーディングスタイルの歪な文化をひとつ増やすだけでも迷惑。
367:デフォルトの名無しさん
08/03/03 07:37:40
それはアノテーションのことかクロージャーのことか、どれの事言ってんだ?
368:デフォルトの名無しさん
08/03/03 08:14:48
Java学習暦2ヶ月の厨房が吠えてるんでしょうｗ春だしｗ
369:デフォルトの名無しさん
08/03/03 09:01:12
------------- ここまでテンプレ -------------
370:デフォルトの名無しさん
08/03/03 09:28:05
----------- ここからプロローグ -----------
371:デフォルトの名無しさん
08/03/03 21:16:39
>>366
そうではない。
進化をとめた言語は、死んだも同然。
C++を見てみろ。
372:デフォルトの名無しさん
08/03/03 21:18:17
C++は革新だらけの言語だが…
むしろ革新多すぎw
373:デフォルトの名無しさん
08/03/03 21:24:41
C++0x はどうせ VC++ で実装されないと踏んでるのですね。
ありえそうで怖い。
374:デフォルトの名無しさん
08/03/03 21:29:16
C99はいつになったら
375:デフォルトの名無しさん
08/03/03 21:34:49
C++だって糞みたいな提案は拒否されてる。>>366に同意。
376:デフォルトの名無しさん
08/03/03 21:41:01
お前らごときが何エラそうに評価してんだｗ
377:デフォルトの名無しさん
08/03/03 21:43:52
お前ごときが口出しするな
378:デフォルトの名無しさん
08/03/03 21:48:45
ﾌﾟｯ
2ch で吠えるなよ～ ｷｬﾝｷｬﾝｗ
379:デフォルトの名無しさん
08/03/03 22:05:32
じゃこのスレいらないね
380:デフォルトの名無しさん
08/03/03 22:06:21
>>374
GCC拡張で良いんじゃね？
381:デフォルトの名無しさん
08/03/03 22:08:53
VCで実装うんちゃらとかいってる時点で厨房だろｗｗｗｗここJava擦れだしｗｗ
花見気分で様子見してろよｗｗｗｗ分かるからｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
382:デフォルトの名無しさん
08/03/03 22:15:39
厨房注意報出てるんだから、スルーしろよ
といってもこのスレの住人レベルじゃ無理だろうけどｗ
383:デフォルトの名無しさん
08/03/03 23:17:29
NonNullとかでガチガチにしても結局たいして意味ないんだよな
384:デフォルトの名無しさん
08/03/04 00:44:12
ヌルポが回避できたって、テキトーな初期値が入れられるだけなんだったら意味無いからな。
それなら、ヌルポ出して、その変数に入れるべき値を考察させればいい。
385:デフォルトの名無しさん
08/03/04 02:36:17
ラムダがint hoge => hoge という形になると
Javaは生涯C#に追いつけないことが確定するからな
386:デフォルトの名無しさん
08/03/04 07:24:02
>>380
いつになったらVLAを関数に渡せるようになるの
387:デフォルトの名無しさん
08/03/04 08:10:47
未だにJavaとMS（VC++VBC#)を比べてるガキがいる件について語ろうではないか
388:デフォルトの名無しさん
08/03/04 11:23:39
Javaは一生懸命C#に追いつこうと機能追加しとるじゃない
389:デフォルトの名無しさん
08/03/04 11:28:39
ちなみにプロパティも属性もボクシングもC#は1.0からもってる
クロージャは2.0で持ってる
今は3.0ね
390:デフォルトの名無しさん
08/03/04 11:44:16
ニートはこんなすれに粘着してないで早く面接行けよｗ
391:デフォルトの名無しさん
08/03/04 18:40:02
C#のプロジェクトって早くもデスマってるのが多いよ
392:デフォルトの名無しさん
08/03/04 18:45:28
C#は始めから迷走してるからな。何がやりたいのか分からん
393:デフォルトの名無しさん
08/03/04 18:53:44
>>391
このスレ関係ないし、まったく興味ないから知らないな。
例えばどれ？
394:デフォルトの名無しさん
08/03/04 19:04:03
>>393
関係ないといいつつ話を継続させようとするな
395:デフォルトの名無しさん
08/03/04 19:14:50
じゃ、はよ消えてくんろ
396:デフォルトの名無しさん
08/03/04 19:34:36
>>393
馬鹿かおまいはｗ
397:デフォルトの名無しさん
08/03/04 19:45:52
今IT業界ではJavaこそが諸悪の根源とされてるのを知らんのか
398:デフォルトの名無しさん
08/03/04 19:53:58
いやおまいらみたいな無能労働層だろｊｋ
399:デフォルトの名無しさん
08/03/04 19:56:38
>>392
C#は1.0の時から3.0の機能は全部予定してたから今のところ何の破綻もない
一直線だ
むしろ迷走してるのはJavaだな
言語仕様を民主的に決める必要なんてかけらも無いのに
400:デフォルトの名無しさん
08/03/04 20:02:23
Javaは方向性も、ビジョンもないからな。
ほんと、これからどうして行きたいのかがわからん
401:デフォルトの名無しさん
08/03/04 21:58:06
このC#厨房は何をしにきたたたたたたたたんだ？
402:デフォルトの名無しさん
08/03/04 22:01:41
自慢しに来た
403:デフォルトの名無しさん
08/03/04 22:06:36
まあ実際、近視眼的な部分はあるよ。
JCPはとどのつまり企業連合な組織だし。
EE6でSpringやS2が壊滅したらちょっと面白い。
404:デフォルトの名無しさん
08/03/04 22:48:56
まぁ、いまのところEE勢が壊滅した事しかないのが笑えるよな。
405:デフォルトの名無しさん
08/03/04 23:05:31
なんかunrestricted closureも実装してきているなあ。> BGGA実装
jsr166z.forkjoinもかなりいろいろ増えてるし。
Control invocation syntaxが楽しくてたまらん(ﾊｧﾊｧ
406:デフォルトの名無しさん
08/03/04 23:12:13
クロージャは次期採用はほぼ固まったみたいでもう追いかけてないんだけど、どお、便利？
407:デフォルトの名無しさん
08/03/05 00:27:08
無名内部クラスがあるのにクロージャも作るのか
408:デフォルトの名無しさん
08/03/05 02:34:54
>>406
import java.util.*;
enum s { This, is, a, test; };
public class I {
public static void eachEntry(List<s> l, { s ==>void } block) {
for (s i : l) {
block.invoke(i);
}
}
public static void main(String[] args) {
List<s> l = Arrays.asList(s.values());
for (s i : l) {
System.out.println(i);
}
eachEntry(s i: l) {
System.out.println(i);
}
}
}
409:デフォルトの名無しさん
08/03/05 10:09:05
ruby使ってる奴らは未だにクロージャとイテレーターの区別ついてないだろうけど。
javaやるとクロージャはどういうのかがやっと理解できるのかもな。
410:デフォルトの名無しさん
08/03/05 10:11:44
連中にクロージャなんて意識ないだろ？
411:デフォルトの名無しさん
08/03/05 10:21:06
レスはえーなｗ
javaの連中もイベント処理でクロージャ（匿名クラス）使ってるって意識はないだろう
イテレータよりは匿名クラス・デリゲートｗのほうがクロージャっぽいけど、まあどっちも同じだ
で、使ってみた感想は将来有望とか利用できるアイディアはいろいろ浮かんでくるか？
412:デフォルトの名無しさん
08/03/05 17:31:20
もうJavaはすててScalaでいいんじゃね？
413:デフォルトの名無しさん
08/03/05 18:35:20
俺はrhino派だな。手続き型+OOP+関数型のマルチパラダイムは便利だ。
414:デフォルトの名無しさん
08/03/05 18:36:24
クロージャと匿名クラスは違う
ローカル変数をクロージャが実行される時まで取っておくのが
クロージャの性質だ
415:デフォルトの名無しさん
08/03/05 18:37:18
final 宣言すりゃとっておけるじゃん。
416:デフォルトの名無しさん
08/03/05 18:53:02
たとえばオープンした後自動的にクローズするような処理にもクロージャは便利だ
new File(path).Read(Input in){
...
}
ブロックを抜けたあと勝手にCloseしてくれるようにできる
417:デフォルトの名無しさん
08/03/05 19:05:43
>>414
interface Guess{ int guess(); }
class Fuga{
static Guess hoge(final int i){
return new Guess(){ public int guess(){ return i; } };
}}
個人的にはイテレータとか作るときに使う。
418:デフォルトの名無しさん
08/03/05 23:38:12
>>414>>415
サンプル実装では、
・@Sharedアノテーションを付けた変数は、バインディングがヒープに作られ、
スコープ内にあるクロージャで持ち運ぶ事ができる。書き換えても結果が共有される。
(スティール大先生のクロージャ・コメントの通りの仕様
暗黙のヒープ確保はしないのがJava流)
・BGGA v0.5の通り、finalな変数は持ち運べる。
の両方が可能。
v0.6が出て、@Sharedに相当する修飾子が出来るのかどうか、
その辺の議論はまだ追えてません。個人的には、
Java7はv0.5の仕様のままで、Java8まで持ち越した方がいいような気がします。
先に解決すべき「Open Issues」があるように思うので。
Doug Lea大先生のjsr166y fork-join frameworkがこなれてきてから、
並列実行での"shared"も同時に解決するようなスキームが望ましいと思うので。
419:デフォルトの名無しさん
08/03/05 23:41:19
>>405
> Control invocation syntaxが楽しくてたまらん(ﾊｧﾊｧ
構造化プログラミングでいうところの構造的な制御構造は何でも作れますね。
ifとかwhileとか。
継続とtail jumpがないから非構造的な制御構造は無理だけど。
ただサンプル実装では、>>405の通り、
returnでクロージャの外の関数を出られる実装が出てきそうだけど。
420:デフォルトの名無しさん
08/03/05 23:50:11
参照渡しはまだかね。
421:デフォルトの名無しさん
08/03/05 23:53:00
finalな変数だけ運べれば十分な気がするな
普通の変数を突っ込まなきゃならないケースが思いつかないし
ややこしくて危険でもある気がする
422:デフォルトの名無しさん
08/03/05 23:54:18
finalじゃなくても適当にfinalを仮定してくれればいいやー
423:デフォルトの名無しさん
08/03/05 23:57:14
ローカル変数がスコープ外の影響受けるなんてのは漏洩の副作用と言った方が良い。
リターンバッファのようにあからさまに意図したものならともかく。
424:デフォルトの名無しさん
08/03/05 23:58:33
アノテーションにまで手を伸ばすのは止めて欲しいな。
こんなんじゃXML hellがAnnotation hellに置き換わるだけだ。
425:デフォルトの名無しさん
08/03/06 00:13:42
全く。
アノテーションは、プログラムに付ける付箋紙のような役割から
ロジックと複雑に絡み合ったカオスの元になりつつあるな。
プログラム的な定義は、言語として定義してくれ。
@Shared アノテーションは、アノテーションの誤用としか思えない。
426:デフォルトの名無しさん
08/03/06 00:24:43
勝手な言語拡張をするんじゃなくて、
処理系独自の意味を与えられる(Cの#pragmaのように)
アノテーションを使っているだけだと思います。
もし必要だということになれば、修飾子になるのでしょう。
Doug Lee大先生が今この辺りのことをどうしているかは追えてないです。
ただ並列に動いているクロージャ同士が、
「環境」を共有しているって状況はとても自然で、応用によっては有益なので、
full closureはいつか入るだろうし、また入るべきだと思います。
427:デフォルトの名無しさん
08/03/06 00:26:23
>>425
サンプル実装と仕様提案を混同して議論しないようにしましょう。
>>418に書いたのはサンプル実装のことで、
@Sharedを使うなんて提案は全くありません。
428:デフォルトの名無しさん
08/03/06 00:27:13
Swing App frameworkのActionアノテーションも間違ってる気がする
429:デフォルトの名無しさん
08/03/06 00:31:41
環境といえば、JSR-323が否決されてたような。
430:デフォルトの名無しさん
08/03/06 00:35:45
試行錯誤中だし、戯言に付き合うのも程ほどにｗ
431:デフォルトの名無しさん
08/03/06 00:39:37
JSR-323って、サマリを見たら昔流行った
MobileAgent系の話のように見えるけど、なんでOS仮想化技術が出てくるんだろう・・・？
Voteのコメントが、何か学生の研究に対するコメントのようで笑えてしまった。
432:デフォルトの名無しさん
08/03/06 00:39:54
List<Action> list = new List<Action>();
for(int i = 0; i < 10; ++i)
{
list.Add( () => Console.WriteLine(i) );
}
foreach(Action action in list)
{
action();
}
これがC#では 10,10,10...と10が10回繰り返される。
finalを付けなきゃいけない場合は
for(int i = 0; i < 10; ++i)
{
final int x = i;
list.Add( () => Console.WriteLine(x) );
}
こうすると0,1,2,3,4...と狙ったような結果になってくれる
まあC#にはfinalないけど
433:デフォルトの名無しさん
08/03/06 00:53:29
歴史的クロージャ
434:デフォルトの名無しさん
08/03/06 00:58:50
>>431
あそこで言っている仮想化は、
OSに対して行う仮想化じゃなくて、
OSがリソースに対して行う仮想化。
例えば、JavaにIPアドレスをmobile可能にする細工を入れるんじゃなくて、
Mobile IP使えば解決する、まあそんな話。
幾らなんでも早急だったと思うし。研究としては悪くないけど。
435:デフォルトの名無しさん
08/03/06 09:44:35
昔はやっと言うよりも、当時の技術（特にハード）で実用的じゃなくて破棄されたけど、
今なら出来そうだというところが大きいんじゃないか。
次は見た目関数型らしきのも入れて、そんなJavaはsmalltalkとかを中心とした昔の技術の集大成でしかないしｗ
436:デフォルトの名無しさん
08/03/06 09:47:15
昔に流行った
437:デフォルトの名無しさん
08/03/06 10:02:45
>>432
ここは最新追っかけだし、せっかくならJava話をしてC＃の話もついでに披露してくれないか
たとえば、おまえの頭にはMacやLinuxにはすごいハッカーがたくさんいるとか考えた事もないだろ？
438:デフォルトの名無しさん
08/03/06 10:07:22
>>437
何いってんのかわかんねえけど俺はクロージャにはfinalなローカル変数が入れられれば
十分だと思っていて、C#ではfinal以外が入れられることでどういう不都合が起こるかを述べている
439:デフォルトの名無しさん
08/03/06 10:14:16
>>438
>>432って不都合か？ せいぜい「評価されるタイミングが俺の好みじゃない」っつーだけのような。
初心者が使いやすい、あんな記述やこんな記述でトラブルの元になってるとか、
そこらへんまで言わないとfinal以外が入れられると不都合、って話にはならんような。
440:デフォルトの名無しさん
08/03/06 10:14:19
>>437
お前痛いよ
441:デフォルトの名無しさん
08/03/06 11:37:23
>>439
C#の話はいいです。
442:デフォルトの名無しさん
08/03/06 12:05:48
>>441
C#の話じゃないって。
unrestricted closure には、取り囲むスコープの変数なら final も @Shared もなしで取り込める。
443:デフォルトの名無しさん
08/03/06 12:38:30
unrestrictedはJava7には入りそうにないね。
444:デフォルトの名無しさん
08/03/06 13:17:41
結局C＃とかC＋＋の部外者がいると荒れるわけですか
少し花見でもしてたつもりですけど、それなら徹底的に排除するまでですけど？
445:デフォルトの名無しさん
08/03/06 13:25:25
>>437
linux, macの奴らはC#など触ったこともないだろ。
奴らの話を聞くだけで耳が腐るｗ
所詮C＃はドカタ候補専用だしな
446:デフォルトの名無しさん
08/03/06 13:34:48
だから言ってるだろ？C＃厨房の相手なんかするなよｗ
447:デフォルトの名無しさん
08/03/06 13:36:54
>>443
仮に unrestricted が入らなくても @Shared やら、
final int[] みたいに似非参照化すりゃ同じ事ができるわけで。
それにv0.5の仕様には
> All free lexical bindings - that is, lexical bindings not defined within the closure literal -
> are bound at the time of evaluation of the closure literal to their meaning in the lexical context
> in which the closure literal appears.
とかバッチリ書いてあるしなぁ。
unrestrictedが入りそうにないって話も信憑性無いし。
448:デフォルトの名無しさん
08/03/06 13:38:43
そうだな。C＃なんて脳みそはVBの奴らとドッコイなのに、こいつらとJavaを同じにされちゃたまらないな。
いつの時代もMSの奴らはキモイってことだな
449:デフォルトの名無しさん
08/03/06 13:56:44
>>447
javac.infoの実装だと、
unrestrictedは==>で区別することになってますね。
=>はjava.lang.RestrictedFunctionなクロージャ。
450:デフォルトの名無しさん
08/03/06 14:03:34
>>449
それは知ってる。
けど unrestricted 入れないつもりなら unrestricted と restricted の区別なんか必要ないんだから
java.lang.RestrictedFunction 自体要らないでしょ。
451:449
08/03/06 14:04:30
でしょって俺に言われても困るけどねw
452:デフォルトの名無しさん
08/03/06 14:20:49
>>440
おれにはJava最新追っかけスレでC#のことをウダウダ言う奴の方がどう見ても痛い
たぶんおまえの方が痛いｗ
453:デフォルトの名無しさん
08/03/06 14:22:52
C#しか脳がないニートは、はよ面接行けｗｗ
454:デフォルトの名無しさん
08/03/06 14:37:56
MS厨ってどこにでも沸くKYだな
455:デフォルトの名無しさん
08/03/06 14:38:23
> Any visible local variable that is initialized or assigned exactly once in the enclosing scope,
> as well as any visible parameter to an enclosing method that is never otherwise assigned,
> is accessible but not assignable within the body of the CICE, whether or not it is explicitly qualified as final.
CICEのルール、BGGAのプロトタイプに導入されてるね。
456:デフォルトの名無しさん
08/03/06 14:57:51
クロージャ厨房も同じくウザイ
457:デフォルトの名無しさん
08/03/06 15:03:45
あと変更入りそうなのは non-local return と local return あたりかなぁ。
{ => method(); } と { => method() } と、ぱっと見て区別つかん。
458:デフォルトの名無しさん
08/03/06 15:22:52
>>455
@Shared も CICE の↓の public とほとんど同じだし、
いいところはマージしてるんじゃ
public int count = 0;
Arrays.sort(array, Comparator<Integer>(Integer v1, Integer v2){
count++;
return v1.compareTo(v2);
});
System.out.println(count);
459:デフォルトの名無しさん
08/03/06 15:41:22
>>418
今日落としたプロトタイプ実装だと、
@Sharedつけなくても警告がでるだけでコンパイルエラーにならんような
これ、ホームページには updated 2008-02-22 って書いてあるけど、
解凍すると closures-2008-03-05ってディレクトリができる……
コッソリと何か変わってたりするんだろうか？
460:デフォルトの名無しさん
08/03/06 16:36:45
ああ、それなら最近変ったんじゃないかな。> @Sharedいらず
2008-02-26ってのもあるし。
461:デフォルトの名無しさん
08/03/06 19:22:17
2008-02-12 が残ってたから @Shared なしを試してみたけど
警告は出るけどコンパイルエラーにはならなかった。
462:デフォルトの名無しさん
08/03/06 19:37:46
単にコンパイルエラーにするのが面倒なだけじゃね
463:デフォルトの名無しさん
08/03/06 20:12:41
クロージャの話を他の言語で例示しただけでフルボッコされるなんて、
このスレじゃまともな技術的議論はできそうにないな
464:デフォルトの名無しさん
08/03/06 20:27:43
そりゃ保守の集まりでしかないから論議なんかはじめからする気ないんじゃ。
JCP = バチカン、JSR = 教典、それ以外の論議 = 異端 = 叩き、な
ご熱心な殉教者しか居ないのは昔からの事。あ、こりゃ保守というか権威主義か。
465:デフォルトの名無しさん
08/03/06 21:12:55
おまえ毎日同じこといってるな
466:デフォルトの名無しさん
08/03/06 21:14:48
そりゃこんだけ毎度同じパターンばかり見せれるとな。
467:デフォルトの名無しさん
08/03/06 21:26:17
で、Javaのクロージャの場合>>432は
10,10,10...？0,1,2,3,4...？
468:デフォルトの名無しさん
08/03/06 23:18:14
保守の集まりというのは以前も書いてあったけど、一体どういうことだよ。
バチカンとか経典とか、お前頭は相当おかしくなっちまってるようだなｗ
469:デフォルトの名無しさん
08/03/06 23:20:00
C++（C#?)のやりすぎだろ。ストールマンの友達かなんかだろ。たぶん。
470:デフォルトの名無しさん
08/03/06 23:32:55
>>463
技術的な議論とかしたいなら、せめてJavaスレにふさわしくJavaでやれよ。
C＃スレでPHPとかVBとかで議論wとか通用しないのと同じだろ。
これに気がつかないおまえのバカさ加減にあきれるw
471:デフォルトの名無しさん
08/03/06 23:33:08
>>432
それスタックの状態を保存するという考えに基づけば正常な動作じゃないか？
472:デフォルトの名無しさん
08/03/06 23:35:33
>>463
もうおまえはこのスレに来なくていいよ。おまえみたいな奴が一人でもいると、スレが荒れるだけだから。
473:デフォルトの名無しさん
08/03/06 23:37:22
>>464も忘れてたｗ
バチカンとか意味不明な奴もお花畑板いけよw
474:デフォルトの名無しさん
08/03/06 23:39:11
間違えてageちまったじゃねーかよー
どうしてくれるんだ？おい、おまえら！！
>>463-464
おまえら責任とれよな
475:デフォルトの名無しさん
08/03/06 23:40:12
何だこの酔っ払い
476:デフォルトの名無しさん
08/03/06 23:41:22
英語は使えなくても叩くときだけは大張り切りですな。
477:デフォルトの名無しさん
08/03/06 23:48:20
>>464
こういうことは言うのは派遣かニートだろ。
こんな社会のカスは相手にすんなよ。
違うスレでは「ニート達よ団結せよ！」とかいってる奴だからw
478:デフォルトの名無しさん
08/03/06 23:51:25
真・スルー 何もレスせず本当にスルーする。簡単なようで一番難しい。
偽・スルー みんなにスルーを呼びかける。実はスルーできてない。 ← >>477
予告スルー レスしないと予告してからスルーする。
完全スルー スレに参加すること自体を放棄する。
無理スルー 元の話題がないのに必死でスルーを推奨する。滑稽。
失敗スルー 我慢できずにレスしてしまう。後から「暇だから遊んでやった」などと負け惜しみ。
願いスルー 失敗したレスに対してスルーをお願いする。ある意味３匹目。
激突スルー 話題自体がスルーの話に移行してまう。泥沼状態。
疎開スルー 本スレではスルーできたが、他スレでその話題を出してしまう。見つかると滑稽。
乞食スルー 情報だけもらって雑談はスルーする。
質問スルー 質問をスルーして雑談を続ける。
思い出スルー 攻撃中はスルーして、後日その思い出を語る。
真・自演スルー 議論に負けそうな時、ファビョった後に自演でスルーを呼びかける。
偽・自演スルー 誰も釣られないので、願いスルーのふりをする。狙うは４匹目。
３匹目のスルー 直接的にはスルーしてるが、反応した人に反応してしまう。
４匹目のスルー ３匹目に反応する。以降５匹６匹と続き、激突スルーへ。
479:デフォルトの名無しさん
08/03/06 23:51:43
英語云々以前に、クロージャのネタも深すぎでウザイ
明日も分からない全然決まってもないことだろ
久々にすれ盛り上がってるけど、他にネタないのか
結局は海外のソースに依存することになるんだろうけど、jdk1.8ねたとか、
いまホットなライブラリネタとかないの？
480:デフォルトの名無しさん
08/03/07 00:00:27
>>477
何この必死君
481:デフォルトの名無しさん
08/03/07 00:02:00
>>478
これ初だけど、いつのコピペ？
というかスルー以前（あおりとかあらし以前）に
次世代JavaスレなのにC＃とかC＋＋とかスレ違いじゃないかのか？
C＃とかC＋＋で出来てるだろ、だからJavaでもやれよって論法が多いが、こいつらサルだろｗ
482:デフォルトの名無しさん
08/03/07 00:03:09
>>479
ホットなライブラリ(笑)
483:デフォルトの名無しさん
08/03/07 00:03:40
>>480
いや、バチカンとかぬかす奴よりは、やつの言い分の方が正しい
484:デフォルトの名無しさん
08/03/07 00:05:15
で、「保守の集まり」ってのは一体何のことか説明してくれないか？
おまえ、いつも同じこといってるだろ
485:デフォルトの名無しさん
08/03/07 00:08:32
ここは誰かが JCP の動向を翻訳してくれるのを口を空けて待ってるスレですよ。
たまに自分が判定する側の人間になってると勘違いしてる人もいるようですけど。
486:デフォルトの名無しさん
08/03/07 00:13:31
>>477
このスレ初めて見ただけど、確かにそいつはゴミみたいなやつだな。
というか、そばに同じようなキモイ奴がいるんだよな。
こいつ、何とかしてやってくれよ。
487:デフォルトの名無しさん
08/03/07 00:18:09
> こんな社会のカスは相手にすんなよ
> このスレ初めて見ただけど
わざわざ自爆宣言するの流行ってるの？
488:デフォルトの名無しさん
08/03/07 00:27:52
>>487
スルー出来んのか？おまえもカスだしなｗ
489:デフォルトの名無しさん
08/03/07 00:33:05
次からテンプレに 「俺様アイディアの披露禁止」 って書いといてくれよ。
いちいち食って掛かるバカが多すぎる。
490:デフォルトの名無しさん
08/03/07 00:33:34
チャットは自粛してくださいな。
知能のある方は以下正常化でよろすく。
491:デフォルトの名無しさん
08/03/07 00:36:25
派遣は明日も早いし5時起きだろ？早く寝ろよｗｗ
ニートはもともと社会のカスだし別にどうでもいいからｗｗｗｗｗ
492:デフォルトの名無しさん
08/03/07 00:40:26
カス達よ団結せよ！
493:デフォルトの名無しさん
08/03/07 00:42:51
>>466
＞見せれるとな。
みせれる？
494:デフォルトの名無しさん
08/03/07 00:47:21
>>492
ワロタｗｗ
495:デフォルトの名無しさん
08/03/07 00:54:49
もう追いかけてないから知らないけど、クロージャの残りの論点は、return, breakをどうするか（表記とかも）ぐらいだろ。
それからscalaとかgooglebyとか勧めてる奴もいるけど、今ならrubyだろうな。
rubyなんて正にモルモンしてるけど、perlほどキチガイじゃない。（上にあったのはバチカンだったか？）
496:デフォルトの名無しさん
08/03/07 00:57:28
このスレひっでえなｗｗｗｗｗ
497:デフォルトの名無しさん
08/03/07 00:59:55
我こそは最前線 Java を追う先駆者と自負されてる方々ばかりですから。
498:デフォルトの名無しさん
08/03/07 01:00:27
Javaの最前線にはひどい人材しかいないようだな
499:デフォルトの名無しさん
08/03/07 01:01:52
＞googleby
多分ネタだろうけど、一瞬googleboyに見えたｗｗｗ
500:デフォルトの名無しさん
08/03/07 01:05:30
>>498
Javaにも最前線にも失礼。
全人類的にこのスレッドは汚物、失礼なものにあたる。
501:デフォルトの名無しさん
08/03/07 01:09:05
>>497
英語は出来ないけどなｗ
502:デフォルトの名無しさん
08/03/07 01:15:28
>>500
早く寝ろよ。派遣先は遠いから明日も早く起きなければいけないんだろ？
503:デフォルトの名無しさん
08/03/07 01:17:42
>>500
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
504:デフォルトの名無しさん
08/03/07 01:18:54
Javaの未来は暗いな
505:デフォルトの名無しさん
08/03/07 01:19:20
>>500
おまえは、カマキリでも食っちまったんじゃないか？
506:デフォルトの名無しさん
08/03/07 01:23:43
IDが無くてもageてるのは同一人物だろうな・・・
jdk7の次のビルドでも出てくれば少しは矛先が変わるのになぁ。
12月からビルド止まったままだし・・・
507:デフォルトの名無しさん
08/03/07 01:28:23
全人類的とかいってる奴、あと保守でモルモン経典うんちゃらとかぬかしてる奴も
一緒に死ねよ。もうおまえの負けだな。
はよオナニーして寝ろｗ
508:デフォルトの名無しさん
08/03/07 01:29:22
506のアドバイスでsage付けるようにしたのか
509:デフォルトの名無しさん
08/03/07 01:30:08
まずID制の導入を嘆願するところから始めなきゃならんな
510:デフォルトの名無しさん
08/03/07 01:36:20
また荒らしか。
511:デフォルトの名無しさん
08/03/07 01:37:44
>>508-510
はよオナニーして寝ろYO
512:デフォルトの名無しさん
08/03/07 01:44:17
ID無くてもBooでがいしゅつになるかで同一チェックできるんじゃないかと思えてきた。
513:デフォルトの名無しさん
08/03/07 01:57:05
>>512
誰だおまえ？
514:デフォルトの名無しさん
08/03/07 02:01:03
>>513
これが噂の負け組みの人だから、かまっちゃダメ！！
515:デフォルトの名無しさん
08/03/07 02:03:03
516:デフォルトの名無しさん
08/03/07 02:30:30
こんなところにも負け組みの人が漂流してるんですね（笑い）
517:デフォルトの名無しさん
08/03/07 02:31:37
ID、IDってうるさい人、あなたも負けたんですか（笑い）
518:デフォルトの名無しさん
08/03/07 02:37:45
ちょっとわからないことがあるのですが、
ゴズリンさんいますか？
519:デフォルトの名無しさん
08/03/07 03:27:18
今日の夜は長いですねｗ
冶金お疲れ様っす！！
520:デフォルトの名無しさん
08/03/07 08:09:52
>>495
Scalaは中の人の議論でもよく出てくる言語だよ。
やっぱりよく出来てる。使ってねーけどw
521:デフォルトの名無しさん
08/03/07 08:16:56
Control invocation syntaxで算術ifも書けるね。うれしい。
522:デフォルトの名無しさん
08/03/07 15:55:38
>>520
使えば分かるよ。Javaから見れば何でもありだからｗ
523:デフォルトの名無しさん
08/03/07 19:51:10
ニート達はもうどっか行っちまったか？
524:デフォルトの名無しさん
08/03/07 22:44:28
ニート、ニートってうるさいんだよ！Java使ったってC＃使ったっていいだろ！！！
525:デフォルトの名無しさん
08/03/07 22:52:21
何この自演ｸｾｰの
526:デフォルトの名無しさん
08/03/08 00:19:40
派遣はいていいですか（・＿・）
527:デフォルトの名無しさん
08/03/08 01:09:17
>>525
ニート乙
528:デフォルトの名無しさん
08/03/08 01:10:46
図星だったか…
529:デフォルトの名無しさん
08/03/08 11:59:23
派遣はいていいですか（・＿・）
530:デフォルトの名無しさん
08/03/08 12:51:33
しつけーよｗいいよ！いていいよｗ、むしろお願いするｗ
531:デフォルトの名無しさん
08/03/08 13:15:38
派遣はいてないですか！？
532:デフォルトの名無しさん
08/03/08 17:01:22
>>530
ニートなんですが…ボクちんもいいですか（・＝・）
533:デフォルトの名無しさん
08/03/08 22:44:17
>>530
誰だってJava使っていいですよね？
534:デフォルトの名無しさん
08/03/09 11:44:37
>>522
何でもできるとかそんなことじゃなくて、すごく良く設計されている。
535:デフォルトの名無しさん
08/03/09 15:38:37
>>534
ボクちんニートなんですが…
536:デフォルトの名無しさん
08/03/09 22:07:15
rubyとscalaの大きな違いは、JavaVM上で動かすことを前提にしているかどうかだな。
537:デフォルトの名無しさん
08/03/09 22:25:37
馬鹿そう…
538:デフォルトの名無しさん
08/03/10 01:34:42
>>478
> 激突スルー
539:デフォルトの名無しさん
08/03/11 11:37:58
どう使うかに絞った簡単な解説
Closures for Java
URLﾘﾝｸ(jazoon.com)
540:デフォルトの名無しさん
08/03/11 19:49:32
ふと思った。例に出てくる for each とかで
for each (String name, Thing thing : myMap) {
if (thing.isCocksucker()) {
return; // ← ｺｲｼはどこに return するのかね？
}
doSomething(name, thing);
}
541:デフォルトの名無しさん
08/03/11 19:57:15
for eachの置かれているメソッドから抜ける。
542:デフォルトの名無しさん
08/03/11 20:24:55
>>540
>>540
>>540
>>540
543:デフォルトの名無しさん
08/03/11 20:45:25
そーいや、BGGA だと Listener系どーすんだろ？
java.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); }
});
}
みたいな感じにすんのかなぁ？ メソッド数が大変な事になるような気もするけど。
544:デフォルトの名無しさん
08/03/11 20:57:59
クロージャより関数オブジェクトとか関数リテラルみたいなラムダの方が欲しいんだけどなぁ。
545:デフォルトの名無しさん
08/03/11 21:32:42
>>544
クロージャと、関数オブジェクトとか関数リテラルみたいなラムダとの違いって？
546:デフォルトの名無しさん
08/03/11 22:20:39
>>543
void 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);
}
547:デフォルトの名無しさん
08/03/11 23:16:07
>>546
それだと順番間違えやすいし、順番間違えてもコンパイル時にチェックできないから
実行時に変な動作してから初めて気付く事になるような……
548:デフォルトの名無しさん
08/03/12 01:37:02
じゃあブロック引数は一つの関数にすればいいんじゃないの？
変な人。
549:デフォルトの名無しさん
08/03/12 08:09:04
それじゃ>>543と変わらん
550:デフォルトの名無しさん
08/03/12 09:22:49
builderパターンを使うってアイデアもあるけど、
実際比べてみると匿名クラス使う場合とタイプ数もあんまり変わらんのよね。
builderパターン + クロージャ：
addMouseListener(new MouseListenerBuilder().setMouseClicked({MouseEvent e => System.out.println("clicked"); }));
adapter + 匿名クラス：
addMouseListener(new MouseAdapter(){ public void mouseClicked(MouseEvent e){ System.out.println("clicked"); } });
551:デフォルトの名無しさん
08/03/12 12:03:38
クロージャってこういう呼び出し方出来ないんだろうか・・・。
({arg => hogehoge})(arg);
552:デフォルトの名無しさん
08/03/12 12:06:59
クロージャーよりもやっつけで盛り込んだ既存のライブラリ仕様を洗練させて欲しいんだが。
553:デフォルトの名無しさん
08/03/12 12:34:23
>>551
BGGA v0.5にはない。
554:デフォルトの名無しさん
08/03/12 12:34:44
洗練って・・・
下位互換考えるともう変更できんだろ・・
555:デフォルトの名無しさん
08/03/12 12:37:22
>>551
それだと単なるキャストだね。
argがクラス名と変数名/フィールド名で重複してるけど。
556:デフォルトの名無しさん
08/03/12 12:39:02
>>552
openjdkあたりにパッチ送れば？ acceptされるとは限らんけど。
557:デフォルトの名無しさん
08/03/12 12:43:30
というか勝手にクラスライブラリ作ればいい。
将来採用されることもありうる。
558:デフォルトの名無しさん
08/03/12 13:50:47
必要になれば、Cのtypedefみたいなのでもっとパワーアップしてるのがサポートされるんじゃないか。
タイプ量が多いとかはエイリアスで解決できるわけで、クロージャの言語仕様とは全く関係ない。
といいつつもJavaではtypedefみたいのは永遠とサポートされないと思うけど。
559:デフォルトの名無しさん
08/03/12 14:21:24
typedefとマクロはないだろうな
560:デフォルトの名無しさん
08/03/12 15:14:22
JavaFX はどうなったのさ。
561:デフォルトの名無しさん
08/03/12 16:00:16
>>558
ヘッダファイルを使うC言語と違って、
Javaのコンパイル単位はtypedefと相性悪いでしょ。
publicクラス毎に、何回も同じtypedefを書く必要出てくるし。
あと、typedef入れるより型推論が入った方が嬉しいぞ。
562:デフォルトの名無しさん
08/03/12 17:09:38
Cのtypedefのパワーアップとして考えられるのは、文字通りtype definedのこと。
型推論と似てるけど、型推論は動的にやるでしょｗ
もしあるなら、typedefは静的におこなわれる、型(class)別名で、
変数のようにスコープを持つとかなら、
CやC++ templeteのようにバグとか追跡不可能で
エラーメッセージも意味不明にまでなったりしないと思う。
だから、やっぱり長いしタイプ量が変わんないじゃんというのは分かるけど、
タイプ量が多いのとクロージャとは関係ない。
563:デフォルトの名無しさん
08/03/12 17:13:03
今やるならアノテーションになるけど、
結局はtypedefやりたいならアノテーションつかってツール作って自分でやってくれよってなるんじゃないか。
564:デフォルトの名無しさん
08/03/12 17:16:42
Adaのtypedefならいいわけか
565:デフォルトの名無しさん
08/03/12 17:56:30
typedefというよりも、別名（エイリアス）ってのがあればいいってわけだ
566:デフォルトの名無しさん
08/03/12 18:25:48
>>562
タイプ量が多いのとクロージャは関係ないよ。
タイプ量が多いと builderパターン+クロージャで
リスナを生成するのが面倒くさいってだけで。
それに別名定義できても、C言語のヘッダファイルみたいなものがないと
それほど便利にはならないっしょ。それよりは型推論の方がいいって事。
型推論も別名定義も両方あってもいいけどさ。
567:デフォルトの名無しさん
08/03/12 18:35:57
そーいや、>>45には type aliasingあるけど、これも続報ないからどーなってんのかわからんね。
もっとも、これは generics でバカみたいに長くなった型名を短くてわかりやすいものにするのが
主な目的っぽいから、>>550 みたいに generics使ってない上に、
MouseListenerBuilder やら setMouseClickled やら MouseEvent やらの
個々の識別子は長すぎて読み易さを低下させてる、ってわけでもないのに
使うようなモンでもねーと思うが。
568:デフォルトの名無しさん
08/03/12 18:47:24
もういっそプリプロセッサがあれば良いんじゃね？
569:デフォルトの名無しさん
08/03/12 19:22:09
>>567
>>550ならtype aliasingいらんだろ。
元から MouseListenerBuilder やら setMouseClicked みたいな名前使わなけりゃいいんだし。
っても、別名使うにしろ、元のから短い名前で定義するにしろ
可読性とのトレードがあるから短い名前考えるのも面倒だわな。
どっちかっつーと、>>116みたいな引数の型推論入れたほうが楽だしタイプ量減る。
builderパターン + クロージャ + 短い名前：
addMouseListener(new MLB().sMC({MouseEvent e => System.out.println("clicked"); }));
builderパターン + クロージャ + >>116みたいな引数の型推論：
addMouseListener(new MouseListenerBuilder().setMouseClicked({ e => System.out.println("clicked"); }));
570:デフォルトの名無しさん
08/03/12 19:24:45
> addMouseListener(new MLB().sMC({MouseEvent e => System.out.println("clicked"); }));
なにこれ
571:デフォルトの名無しさん
08/03/12 19:30:27
>>570
よーするに、可読性落とさないような名前が思いつかないなら
>>550のタイプ量は妥当だって事。
572:デフォルトの名無しさん
08/03/12 21:31:24
そもそも、タイプ量だけなら >>543 使って
onMouseClicked({MouseEvent e => System.out.println("clicked"); });
で良いんだし。もしくは >>543 と control invocation syntax 使って
onMouseClicked(MouseEvent e){ System.out.println("clicked"); }
573:デフォルトの名無しさん
08/03/12 21:42:20
別にクロージャーが入っても何か新しいことが出来るようになったり
下らないミスが減ったりするわけじゃないんでしょ。拡張 for 並みに
どうでもいいんだけど。
574:デフォルトの名無しさん
08/03/12 21:43:13
>>572
エイリアスやらマクロやらプリプロセッサやら出してくるぐらいなら、そっちのがいいね
575:デフォルトの名無しさん
08/03/12 22:01:29
拡張forは便利だろ。
いちいちインデクサなんて書いてられるか可読性も落ちる。
576:デフォルトの名無しさん
08/03/12 22:04:29
インデクサ？ Iterator の間違いじゃね？
577:デフォルトの名無しさん
08/03/12 22:10:25
javax書き換えられないようなsuperpackageはいらない、Sunの失態が無いなら良いけど
578:デフォルトの名無しさん
08/03/12 23:00:42
↑ん？どういうこと？
579:デフォルトの名無しさん
08/03/12 23:01:12
>>575
C#に洗脳されすぎｗ
580:デフォルトの名無しさん
08/03/12 23:03:18
クラスとかメソッド名が長いってだけなら、ビルダークラスとかを継承してオーバーライドして自分で短い名前にしてくれよ。
それぐらい頭使え。
581:デフォルトの名無しさん
08/03/12 23:12:34
void hoge(a){actionPerformed(a);]
で、短いメソッド名で実装して、それを呼び出すことね。
582:デフォルトの名無しさん
08/03/12 23:26:28
indexerって普通の英語なんだが。
583:デフォルトの名無しさん
08/03/12 23:30:00
Javaじゃそんな言葉使わんしここ日本。
584:デフォルトの名無しさん
08/03/12 23:31:02
普通の英語って事は「索引を作る人」って意味で使ってるとか？
585:デフォルトの名無しさん
08/03/13 00:02:39
>>583
お前は日本語でプログラム書くのか？
586:デフォルトの名無しさん
08/03/13 00:16:46
演算子オーバーロードが言語仕様にあれば
Javaでもインデクサって普通に呼ぶだろうね。
Javaもinterface経由で演算子オーバーロードに対応したらいいのに。
AppendableとかCalculateableみたく、目的を明示すれば設計者も馬鹿しないでしょ。
587:デフォルトの名無しさん
08/03/13 00:21:01
演算子オーバーロードは絶対にサポートしないといってたけど。
588:デフォルトの名無しさん
08/03/13 00:28:40
>>585
いやいや、言いたいのは話をわざわざ分かりにくくするために英語にする必要はないだろうということ。
589:デフォルトの名無しさん
08/03/13 00:33:24
C#ちゃんはいいかげんに巣に帰れよ
590:デフォルトの名無しさん
08/03/13 02:05:45
インデクサくらい理解してやってくれ。
ループ抽象(拡張for)
コントロール・インヴォケイション・シンタックス
は過激に便利ですよ。>>539のp4-6見てください。
プログラム構造がかなりすっきりまとまります。
プログラム内でのコードの共通化も進みますし。
591:デフォルトの名無しさん
08/03/13 03:43:59
↑もうこなくていいから。死んでくれ
592:デフォルトの名無しさん
08/03/13 06:40:12
病的な過剰反応だな。明らかにネットに向いてない。
593:デフォルトの名無しさん
08/03/13 14:00:38
>>592
おまえも
594:デフォルトの名無しさん
08/03/13 21:56:17
>>561
別に相性は悪く無いと思う
以下のような感じでstatic importでtypedefを取り込めるような仕様にしておけば
問題無し
-- A.java --
package a;
public class Alias {
type FileName = String
}
-- B.java --
import a.Alias._;
public class B {
public static java.io.RandomAccessFile open(FileName name) {
....
}
}
595:デフォルトの名無しさん
08/03/13 22:49:58
>>594
それをやるには static import とは別の仕組みが必要になるし、
どうせやるなら class Alias みたいなものをヘッダファイルモドキとして使うのは間抜けすぎる。
596:デフォルトの名無しさん
08/03/13 23:59:35
>>595
それ言っちゃおしまいでしょ。
java.lang.Math とか java.util.Collections とか、
クラス外にメソッド置いとけるんならクラス外に置きたいようなのは標準APIにも多いし。
Java でやるなら >>594 みたいなやり方しかないと思うけどね。
597:デフォルトの名無しさん
08/03/14 00:01:58
>>562
> 型推論と似てるけど、型推論は動的にやるでしょｗ
MLなどの型推論はコンパイル時に静的にやるよ。
動的だったら、型を推論するまでもなくチェックすればいい。
>>567が言っているような、
generics使って汎用に書かれたクラスに、
具体的なクラスを与えて、新たなクラスとしてpublicにする、
って機能は必須だと思う。
ただconcept(C++), type class(haskell)のような形の方が
より汎用でスマートだと思う。単なるエイリアスじゃなくて
両クラスのグルーとなるコードも加えられるし。
598:デフォルトの名無しさん
08/03/14 00:05:28
>>596
クラス外メソッド定義とクラスエイリアスは別件。
599:デフォルトの名無しさん
08/03/14 00:15:29
>>598
クラス外メソッド定義したいって言ってるんじゃなくて
言語仕様が許すなら必ずしもクラス内に置く必要ないエイリアスやメソッドを
クラス内に置かなきゃいけないのは等しくアレだって事
600:デフォルトの名無しさん
08/03/14 02:39:52
アノテーションでいいよ。機能的には違うけど、本質的に同じだし。
601:デフォルトの名無しさん
08/03/14 03:01:16
クロージャーなんて既存機能で十分まかなえるものの焼き直しなんかより
もっと AOP 的設計が出来るようなアプローチしろよ。インスタンスフィールドへの
アクセスもトラップできるようにすればそもそもプロパティ拡張もいらんだろが。
602:デフォルトの名無しさん
08/03/14 03:44:37
クロージャで演算子オーバーロードもとラップできるといいけどな
603:デフォルトの名無しさん
08/03/14 05:49:16
> インスタンスフィールドへのアクセスもトラップできるようにすれば
フィールドアクセスがめちゃくちゃ遅くなりそうだな
604:デフォルトの名無しさん
08/03/14 06:29:16
final 宣言されてない getter/setter と同等にできるだろ。めちゃくちゃの根拠が不明。
まぁプロパティアクセスに関しては「後で」「静的に」「他のソースを修正せずに」アクセサを
追加できれば十分だが。
605:デフォルトの名無しさん
08/03/14 06:51:54
また変な奴が常任してしまったな。
606:デフォルトの名無しさん
08/03/14 06:54:17
ＪＳ乙
607:デフォルトの名無しさん
08/03/14 07:11:52
C#厨房よりはましｗ
608:デフォルトの名無しさん
08/03/14 07:28:45
というかおまえ誰だよ
609:デフォルトの名無しさん
08/03/14 07:33:04
俺ビルジョイ
610:デフォルトの名無しさん
08/03/14 07:58:33
ＪＳじゃイニシャル違うじゃんかよ
611:デフォルトの名無しさん
08/03/14 10:58:17
>>604
そか？ 隠蔽されたフィールドに対するアクセスとかも考えたら
プロパティモドキじゃ対応できないし馬鹿みたいにでかい仕組みが必要になると思うが。
612:デフォルトの名無しさん
08/03/14 12:18:31
JKが女子高生なんだからJSは・・・
613:デフォルトの名無しさん
08/03/14 12:22:35
専門学校生だよね
614:デフォルトの名無しさん
08/03/14 12:30:48
>>611
それだけなら何とかなると思うが……
もっとも、リフレクション対応までして「インスタンスフィールドアクセスのトラップ」
できるようにするより他の事にエネルギー使って欲しいぞ。
615:デフォルトの名無しさん
08/03/14 15:49:59
J 常識的に
S ｾｯｸﾙして
616:デフォルトの名無しさん
08/03/14 16:03:51
>>611
現時点でも少なくともリフレクション程度は確保できる。
まぁフィールドアクセスはそれも包含できるという意味で引き合いに出しただけで本意は別。
ゴリゴリ書くしかなかったのを簡素化したいのはもっともだが、なら無名内部クラスより
DI の標準様式一つでも考慮しろと。
617:デフォルトの名無しさん
08/03/14 16:14:40
> DI の標準様式一つでも考慮しろと。
？
618:デフォルトの名無しさん
08/03/15 01:41:01
あれ？JFileChooserが遅いバグって6u5までのどこかで修正入った？
619:デフォルトの名無しさん
08/03/15 10:17:10
>>541
つーか選択肢は二つくらい(?)あって
・クロージャから抜けるのみ ・・ >>540のコードなら、doSomething() が実行されないだけで for each は続く
・for each の置かれているメソッドから抜ける
「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら
前者が選ばれるだろうなと思ってさ。
620:デフォルトの名無しさん
08/03/15 10:19:34
>>619
> 「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら
違う。
621:デフォルトの名無しさん
08/03/15 10:32:19
匿名クラスの構文糖って言いたかったんかな
622:デフォルトの名無しさん
08/03/15 11:45:56
クロージャのreturn周りはどうなるのかホントわかんないな。
ECMAScript風になるのか、ruby風になるのか。
623:デフォルトの名無しさん
08/03/15 11:54:42
C#風に、内容に expression しか書けないクロージャ（ラムダ式）と、
statements が書けるクロージャの2種類作るってのもアリだと思うんだけど。
624:デフォルトの名無しさん
08/03/15 11:54:49
どっちでもない
625:デフォルトの名無しさん
08/03/15 12:41:25
ruby風はありえないだろ
何がどこに抜けるんだかバージョンによって変わるだなんて
626:デフォルトの名無しさん
08/03/15 13:29:50
returnで脱出する最外レベルはメソッドであって、
クロージャやブロックではない。
詳しくは URLﾘﾝｸ(www.javac.info) を読め。
627:デフォルトの名無しさん
08/03/31 04:07:09
Listenerを登録するという設計自体がクロージャと相性が悪いわけか
なんでこんな設計にしたんだ
628:デフォルトの名無しさん
08/03/31 04:15:55
他に手がないからだろ
629:デフォルトの名無しさん
08/04/01 08:58:11
>>627
てか他に手は無いだろ
630:デフォルトの名無しさん
08/04/02 02:03:03
>>627
相性が悪いって程でもないと思うが
確かBGGAでは、function typeをListenerに暗黙に変換するための
仕掛けが用意されるんじゃなかったっけか
631:デフォルトの名無しさん
08/04/02 09:54:37
>>630
ActionListenerみたいにメソッド一個しか無い場合は変換できるけど、
BGGAには、MouseListenerみたいにメソッドいっぱいある場合の変換の仕掛けはないよ。
named inner methodがあるFCM と比べると、BGGAとXxxListenerは相性悪い。
632:デフォルトの名無しさん
08/04/02 10:02:50
URLﾘﾝｸ(tronicek.blogspot.com)
method reference だそーです。
method reference に '#' 使うのが平気な感覚もってるのに
accessing property に '.' 以外の演算子使うのってダメなんかねぇ…… と思ったり。
633:デフォルトの名無しさん
08/04/02 10:50:41
listOfArgumentTypesは必要かね?
継承に絡まない型推論はしない主義だから必要になるのかな。
文脈は常に強く型付けされているはずだが。
634:デフォルトの名無しさん
08/04/02 10:59:04
もう Method の静的解決 (Foo.class みたいな) でええやん。関数ポインタみたく使えりゃええんじゃろ。
635:デフォルトの名無しさん
08/04/02 11:00:07
static import で listOfArgumentTypes 書けるようにしてくれませんかね？
636:デフォルトの名無しさん
08/04/02 19:35:24
>>633
本来なら通常は要らんと思うけど、同名のメソッドがオーバーロードされてる
場合必要になるから、必須にしてるんじゃないかな？
637:デフォルトの名無しさん
08/04/02 19:41:39
それは型情報で分かるから。
638:デフォルトの名無しさん
08/04/02 20:49:02
>>634
ちがうよ。変数スコープが重要
639:デフォルトの名無しさん
08/04/02 21:46:47
>>637
contravariant な変換許すなら、型情報だけから必ず判るわけじゃないから
listOfArgumentTypes 省略しないタイプも必要だと思うぞ。
省略できても良いと思うけど。
640:デフォルトの名無しさん
08/04/02 23:01:51
>>637
(System.out#println(String)).invoke("Foo")
みたいな場合を考えると必要なケースもあるよってこと
もちろん、必要じゃないケースもあるから省略はできてもいいと思う
もちろん、上のような式を実際に書く必要はないだろうけど、文法上
書けるなら対策は必要になるわけだ
641:デフォルトの名無しさん
08/04/09 23:28:18
そろそろjdk1.7はリリースされるの？
642:デフォルトの名無しさん
08/04/10 00:19:26
来年の始め頃じゃないか
643:デフォルトの名無しさん
08/04/10 00:27:41
1.6updateN が出てから 1年ぐらいは必要じゃないかと思うが
644:デフォルトの名無しさん
08/04/10 09:45:57
なんだ。まだか。
645:デフォルトの名無しさん
08/04/10 21:34:28
Java7からと思ってたが、Java KernelはUpdate Nから入るのね。
JMFあたりも自動ダウンロードしてくれるならありがたい限りだけどどうだろ。
646:デフォルトの名無しさん
08/04/18 12:48:24
JDK7 build25
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
647:デフォルトの名無しさん
08/04/19 06:58:13
クロージャーなんかよりも、入出力ストリームや Lock 使った try-finally 使いまくりのコードを
きれいに書ける構文考えてくれよ。synchronized と違和感ないような (これもブロック抜けるときに
モニタ開放するし)。
try(Writer out = new FileWriter("foo.txt")){
...
} catch(IOException ex){...}
↓みたいな。二重tryでもいいや。
Writer out;
try{
out = new FileWriter("foo.txt")){
...
} catch(IOException ex){
...
} finally{
try{ if(out != null) out.close(); } catch(IOException ex){throw new RuntimeException(ex);}
}
648:デフォルトの名無しさん
08/04/19 08:59:28
それは既に入る予定だが?
しかもクロージャを使って。
649:デフォルトの名無しさん
08/04/19 09:30:50
>>647
つ control invocation syntax
650:デフォルトの名無しさん
08/04/24 14:22:07
次のjava7でクロージャ以外で主要な目玉機能ってなんですか？
651:デフォルトの名無しさん
08/04/24 16:03:13
俺はダグ・リー先生のjsr166y.forkjoinがどうなるかが最大の関心事
素晴らしすぎ。
652:デフォルトの名無しさん
08/04/24 16:21:19
今度の JavaOne で dolphin の進捗も発表されんじゃね？
653:デフォルトの名無しさん
08/04/24 17:00:32
クロージャ以外は特にないよ
654:デフォルトの名無しさん
08/04/24 20:05:44
fork-joinはメニーコア時代の必需品になるだろうし重要だと思う。
そんな時代だと永続性ユニットとしてRDBMSだけじゃなく、
これとMemoryMappedFileあたりと組み合わせたやつとか使いそう。
655:デフォルトの名無しさん
08/04/24 21:35:45
FileじゃなくてOODBください ＞＜；
656:デフォルトの名無しさん
08/04/27 15:47:45
いつまでも実現しないMVMは？
657:デフォルトの名無しさん
08/04/29 15:06:35
JDK7 build26
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
658:デフォルトの名無しさん
08/05/04 23:56:54
LINQみたいなのは、はいらんの？
quaereのような式言語っぽいやつじゃなくて言語実装として組み込まれてるのがほしい。
659:デフォルトの名無しさん
08/05/05 00:12:37
スクリプト関連ほんとに追加されるのかな～
660:デフォルトの名無しさん
08/05/13 03:23:42
スクリプト関連は、やるだろうね。
Java一本が難しくなった今、他言語のサポートは急務
LINQみたいなのは、能力的に無理そう。
661:デフォルトの名無しさん
08/05/16 19:50:57
method refarenceなかなかいいんじゃないの？
Integer#parseInt(String);のやつ
662:デフォルトの名無しさん
08/05/20 00:41:53
JavaFXをプッシュしてるけどSunは、まともなオーサリングツール作る気あるのか？
どう考えても負け戦な気がするんだけど。
663:デフォルトの名無しさん
08/05/20 01:24:56
君にはまだ早すぎる。できる開発者だけの楽しみだしｗ
664:デフォルトの名無しさん
08/05/20 23:38:25
負け戦は確定でしょ
ただでさえ中心人物がどんどんやめていってるのに
665:デフォルトの名無しさん
08/05/21 15:16:25
SUNは、開発者ごとJavaFXをGoogleにあげればいいと思うよ。
開発者のやる気も出るし、Android標準搭載になっていい事だらけだと思うぞ。
まあもらってくれないだろうが・・・
666:デフォルトの名無しさん
08/05/21 23:37:07
JavaFXって結局ブラウザの中でも実行できるんだっけ？
デモサイトを見てもブラウザ内で実行できるのが無いんだけど単にJavaFXのブラウザプラグインがまだ無いだけ？
667:デフォルトの名無しさん
08/05/21 23:43:12
全部javaで書いてあります。> JavaFX
668:デフォルトの名無しさん
08/05/21 23:47:01
えーとね、スクリプトをサポートする順番は、sunの発表では、rubyとかはあるけどFXは全く予定にないってところだった。
まだ熟してないんだよ。そーあせるなってｗ
669:デフォルトの名無しさん
08/05/22 00:18:10
熟すときは来るのか？ｗ
670:デフォルトの名無しさん
08/05/22 07:10:25
SM次第でSMのシルバーなんとkがが市場を開拓すればおのずと、
知らないだろうけど、フォトランのsun風味とかもあるし、
671:デフォルトの名無しさん
08/05/23 11:09:35
JDK7 build27
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
672:デフォルトの名無しさん
08/05/26 12:02:22
JDK6でせっかく入れたTools APIはjava7のリッチクライアントプロファイルでは外されるんだな。
Tools APIってJDK6で入っただけでまだ標準ライブラリ化してないんだっけ？
673:デフォルトの名無しさん
08/05/26 12:09:04
>>672
リッチクライアントプロファイルからはjavacとか削るつもりなんだろ。
プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。
だからTools APIが削られる事と標準かどうかは関係ない。
674:デフォルトの名無しさん
08/05/26 13:47:38
プロファイルはJREの話だからjavacがないのは元からだ。
toolsAPIはJREのrt.jarに入ってるから削られる。
675:デフォルトの名無しさん
08/05/26 14:18:04
>>674
このスレの主だから。こいつは、なんつーか傲慢で非常にひねくれた性格なのよｗ
確かageたりすると、こいつ、すぐ発狂するからｗｗ
676:デフォルトの名無しさん
08/05/26 14:20:08
＞プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。
だからTools APIが削られる事と標準かどうかは関係ない。
この「だから」ってのはどうつながっていて、標準ライブラリとTools APIとどういう風に「関係がない」のかちゃんと説明できるの？
偉そうに適当な事ばかり言ってないでさ
677:デフォルトの名無しさん
08/05/26 14:39:12
AWT/Swingが削られるのはヘッドレスプロファイルだろ。サーバーサイド向け。
けどjava2Dの一部ってAWTだよな・・・。
678:デフォルトの名無しさん
08/05/26 14:54:49
headless はマジで助かる。
Ubuntuにheadlessのopenjdkが入って助かった。
でないとサーバ用途なのに、画面周りが必要だったり困りもの。
679:デフォルトの名無しさん
08/05/26 14:59:42
1.4以降なら -Djava.awt.headless=true つけりゃヘッドレスモードになったような。
680:デフォルトの名無しさん
08/05/26 15:00:26
Ubuntuはもうjdk6u10入ってるのか。
新java-pluginって単にJavaFXでブラウザからドッカブルにしたかっただけだよね。
J++が吐いた糞バイトコード食ってブラウザ毎VMおとされる心配がなくなったから良いが。
681:デフォルトの名無しさん
08/05/26 15:09:12
>>679
ん、そうなんだけど、インストール時はdependencyの関係上画面周りの
インストールが必要だったのよ。使わないのに。
682:デフォルトの名無しさん
08/05/27 19:24:21
このスレにもageると発狂する奴がいるのか？
683:デフォルトの名無しさん
08/05/27 20:13:57
研究室も貧乏臭くて真っ暗なんじゃね？図星だろうｗｗ
684:デフォルトの名無しさん
08/05/28 19:35:25
研究室にテロでも仕掛けるのか？
自分でまねいた種だし、いっちょやっつけちゃってよｗｗ
685:デフォルトの名無しさん
08/06/01 16:29:28
研究室にテコを仕掛けてきますた。
見事に釣り合っております。
686:デフォルトの名無しさん
08/06/06 19:12:40
JDK7 build28
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
687:デフォルトの名無しさん
08/06/07 07:16:41
教えて君ですまない。
build28というのはどのくらいの進捗なの？
クロージャやプロパティは使えるようになってますか？
688:デフォルトの名無しさん
08/06/07 08:00:59
> build28というのはどのくらいの進捗なの？
まだまだ。
> クロージャやプロパティは使えるようになってますか？
なってない。
689:デフォルトの名無しさん
08/06/07 08:02:52
>>687
クロージャ使いたかったら URLﾘﾝｸ(www.javac.info) のプロトタイプ使うのが手っ取り早い。
690:デフォルトの名無しさん
08/06/07 12:06:41
>>688-689
ありがとう。それは残念、待ち遠しいですね。
691:デフォルトの名無しさん
08/06/07 14:56:19
別にイラネ
692:デフォルトの名無しさん
08/06/12 16:02:03
多値関数がホスィ
693:デフォルトの名無しさん
08/06/12 17:43:41
俺も思う
配列で実現する
シンタックスシュガーでいいんだけどな・・・
( String a, String b ) = hoge( c);
が書きたいだけなんだ・・・
Object[] hoge(String c){
}
で定義する、でもいいから・・・
694:デフォルトの名無しさん
08/06/12 18:45:55
バグの温床なので諦めて下さい
695:デフォルトの名無しさん
08/06/12 18:59:38
>>694
どの辺がバグの温床？
696:デフォルトの名無しさん
08/06/12 21:14:57
javascriptでもできるようになったんだよな。
var [a, b] = (function (a, b){returen [a, a + b]})(10, 20);
って・・・。
697:デフォルトの名無しさん
08/06/12 22:44:05
多値とオプション値型は、
ヒープを消費しない形で多用したいので、
組み込みで入れて欲しい。
698:デフォルトの名無しさん
08/06/12 23:54:09
>>697
スタック使うのは、何年か前にBugDatabaseでVMの大幅な変更が必要だから却下って言われてたような。
699:デフォルトの名無しさん
08/06/13 00:54:28
VMって、戻り値に複数スタック渡せないんだっけ？
700:デフォルトの名無しさん
08/06/13 07:13:10
無理
701:デフォルトの名無しさん
08/06/13 10:27:13
多値だけは止めてくれ吐き気がする
あれは本当にたちが悪い
702:デフォルトの名無しさん
08/06/13 10:27:38
VMは戻り値指定にひとつの型しか指定できないし、戻り値を返す命令もireturn lreturn freturnみたいな単一の型指定しかできないので、最低限、戻り値指定と複合return命令を追加する必要がある。
703:デフォルトの名無しさん
08/06/13 10:36:46
invokedynamicでも入るんだから何でも入りそう。
704:デフォルトの名無しさん
08/06/13 11:37:27
invokedynamicと戻り値指定変更の影響範囲の違いもわからないのか。
705:デフォルトの名無しさん
08/06/13 11:51:59
実行時にはa,i,l,f,d,voidしか区別する必要ないんだから、
結構簡単なんじゃないの?
706:デフォルトの名無しさん
08/06/13 12:30:28
じゃあおまえがプロトタイプを作って見せてくれ
707:デフォルトの名無しさん
08/06/13 12:45:29
コンパイラの方も多値は基本的に代入だけだしね。
708:デフォルトの名無しさん
08/06/13 13:06:16
いや、だから、コンパイラが返値をObject[] に変えてくれればいいんですお。
配列の返値はOKですよね？
709:デフォルトの名無しさん
08/06/13 13:12:01
オプション型は、論理型への暗黙の変換か、
match case文がないとダサダサだね。
Javaには入りづらいだろうね。
710:デフォルトの名無しさん
08/06/13 13:30:19
>>705
戻り値の数と組み合わせの管理が必要になるだろ。
711:デフォルトの名無しさん
08/06/13 13:35:23
引数の参照渡しと多値関数どちらかとれといわれたらどっちがいい？
712:デフォルトの名無しさん
08/06/13 13:38:09
どっちもイラネ。
case節で指定できる型を増やしてくれ
713:デフォルトの名無しさん
08/06/13 13:38:22
>>710
それはコンパイル時に終わらないかな?
*loadのスロット参照すればいいから。
714:デフォルトの名無しさん
08/06/13 13:58:13
> *loadのスロット参照すればいいから。
バイトコードベリファイア書き換えないと無理ね。
変更後のバイトコードベリファイアに脆弱性ないかを調べるの面倒だし。
あと、スタックフレームが連続してる保障ないはずだから、
*loadでやるのが可能なのかも疑問だったりする。
715:デフォルトの名無しさん
08/06/13 14:53:31
>>714
連続してなくても＊loadで参照できればいいんじゃないのかな。
コンパイル時にフレームサイズもindexも決まるわけだし。
ベリファイア書き換えはちょっと面倒だね。
invokedynamicみたいな基本ポリシーy面での変更はないけれど。
716:デフォルトの名無しさん
08/06/13 15:08:26
> 連続してなくても＊loadで参照でき
るようにするためには、VMの書き換えが必要になるわけで。
717:デフォルトの名無しさん
08/06/13 15:41:36
というか基本的にフレーム内は連続してる前提でしょ。
もちろん実装に任されているけれど。
多値だって個数はスタティックに決まるんだからフレーム内におさめられるし。
>>714は何が疑問なんだろ。
718:デフォルトの名無しさん
08/06/13 15:44:58
>>717
VM仕様で、異なるメソッドでフレームが連続していなければならないって記述してある箇所あんの？
719:デフォルトの名無しさん
08/06/13 16:01:11
>>718
*returnしたものが、*storeなどで参照できるってことだけだね。
多値が追加されたとしても、その辺の抽象的なVMの定義は変らないのでは。
720:デフォルトの名無しさん
08/06/13 16:02:24
> 3.6 Frames
> 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.
あたりを読むと、モデルとしては完全に分離してるように見えるが。
721:デフォルトの名無しさん
08/06/13 16:03:36
>>708
Arrayだとdoubleとか入れるの困るじゃん
722:デフォルトの名無しさん
08/06/13 16:09:55
>>719
*return した値ってオペランドスタックに置かれるんじゃなかったっけ？
ローカル変数領域だったっけか？
723:デフォルトの名無しさん
08/06/13 16:23:43
>>721
java.lang.Doubleにboxingすりゃいいのでは？
>>693みたいな構文糖でいいって場合は配列生成するんだろうし
コストはあんまし重要視してないんじゃないかと。
724:デフォルトの名無しさん
08/06/13 16:31:45
>>693
> Object[] hoge(String c){
> }
> で定義する、でもいいから・・・
これはありえんだろ。型弱すぎw
725:デフォルトの名無しさん
08/06/13 16:35:48
型の話でいうなら変換前の言語の時点での問題だろ。問題にならんと思うが。
726:デフォルトの名無しさん
08/06/13 17:07:14
Object[]よりも無名クラスのオブジェクトの方が向いてるんじゃないの。
ボクシングの問題とか。
727:デフォルトの名無しさん
08/06/13 17:18:16
裏側でクラス作るくらいなら、Object[]でいいと思う
そんな謎のpublicなクラス作られると気持ち悪い。
728:デフォルトの名無しさん
08/06/13 19:54:19
本当に構文糖にできるなら、Object[]の部分は何かで書き換えられると思う。
で、Genericsのようにチェックはコンパイル時ってことでいいんじゃないかな？
729:デフォルトの名無しさん
08/06/13 20:45:07
>>701
そこにタッチ
730:デフォルトの名無しさん
08/06/13 21:07:15
>>712
それは思うなぁー
確か7でStringのswitchができるようになるとかいう噂もあったよな
あれは是非お願いしたい。
731:デフォルトの名無しさん
08/06/13 22:21:24
最近Scala触ってるんだけど、正直Javaの拡張はもういらない気がしてきた。
欲しいなと思ってたものが殆ど揃ってる。
732:デフォルトの名無しさん
08/06/13 22:38:47
JavaよりJVMの方だな、もっとよくなってほしいのは。
733:デフォルトの名無しさん
08/06/14 04:51:09
Java仮想マシンの仮想化機能: Multi-Tasking
URLﾘﾝｸ(www.shudo.net)
Javaのメモリ消費問題の解決を目指すSunのプロジェクト「MVM」
URLﾘﾝｸ(www.itmedia.co.jp)
ついにベールを脱いだ米SunのリアルタイムJava
URLﾘﾝｸ(journal.mycom.co.jp)
NASDAQも採用進めるリアルタイムJava
URLﾘﾝｸ(japan.zdnet.com)
Java SEのJVMにマルチタスキング機能とリアルタイム機能が盛り込まれたら
用途がもっと広がると思います。
SUNは自分の商売に使いたいから提供しないのでしょうけど、
コミュニティが独自に開発しないのは何か事情があるのでしょうか？
734:デフォルトの名無しさん
08/06/14 09:46:14
どの会社も独自に頑張ってるよ。特にJ2ME。
735:デフォルトの名無しさん
08/06/17 01:25:43
MVMはJNIがある限り厳しいという話をこのスレで読んだような・・・
736:デフォルトの名無しさん
08/06/17 03:53:10
>>735
JNI必要な応用ばかりじゃないし、
MVMの基準に合致するJNIの制約を作ることも可能。
737:デフォルトの名無しさん
08/06/17 10:42:44
MVMのJVMとノーマルのJVMを別物と思えばいいような気がするなぁ。
MVMに乗せるアプリは一定基準を守る事って。
Appletだってそうなんだから。
738:デフォルトの名無しさん
08/06/18 10:54:58
タプルは使ったことないからいまいち、どのあたりが有用なのか分からない。
Object[]で簡易的にやりたくないなら、
class タプル内部クラス
String a,b;
でいいんじゃないの？これや[]を超える有用なのところがなにかあるのかな。
739:デフォルトの名無しさん
08/06/18 16:02:15
何で突然タプルの話なの?
740:デフォルトの名無しさん
08/06/18 17:45:39
>>738
端的に2つ言うと、
・別にタプルとしてまとめて扱いたい訳じゃない
・見やすいから使いたい
です。
741:デフォルトの名無しさん
08/06/24 18:54:00
invokedynamicは命令ひとつ追加するだけっていう単純なものじゃないんだな。
742:デフォルトの名無しさん
08/06/26 01:14:36
publicなfieldにするのにObject[]なんかできんし、
ただ組を表現するのにclass定義とか面倒すぎる
743:デフォルトの名無しさん
08/06/26 04:34:06
Map.Entryでえぇやん
744:デフォルトの名無しさん
08/06/27 12:20:21
JDK7 build29
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
745:デフォルトの名無しさん
08/07/04 08:59:42
JDK7 build30
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
746:デフォルトの名無しさん
08/07/09 00:37:03
＝ ＝ ＝ 寄生虫一家のだんらん ＝ ＝ ＝
パパ「どうだ～ 大画面のプラズマテレビはスゴいだろ～～」
ガキ「スゴいね～ パパ！ これもパパがいつも言ってる愚民からのお金で
買ったの？」
ママ「パパはね、世間がどうなってもたぁ～くさんお金が貰えるし
ボーナスで毎年プラズマテレビと車も買えるんだからぁ～～」
パパ「しかし最近はさぁ～ マイッタよ、職場が禁煙になっちゃってさぁ～
なにしろ30分おきに入り口の外までタバコ吸いにいかなきゃならない
んだからなぁ～、ヘタにそのまま遊びに行くとどこでオンブズマンとか
いう輩が見てるか解らんからなぁ」
ママ「ほんとにあの連中はウジ虫よね！ 自分がなれなかったからって
人の幸せをねたんで」
パパ「まぁ、うちはおじいちゃんの代から公務員だからな、チョロい1次試験
さえクリアすれば2次の面接なんて特攻服で行ったって満点合格なんだ
よ、ハ～ッハッハッ！」
ママ「ボクもね、大きくなったら公務員になるのよ、一生遊んで暮らせるん
だから～～」
ガキ「ウン、ママ！ ボクも公務員になるよ。 ところでさぁ、今年もまた
あのタダの保養所に遊びに行くんでしょ？」
ママ「ママねぇ～ あそこ飽きちゃったのよ、休みはいくらでもあるんだから
今年はパリにでも行ってお買い物したいわぁ～～」
パパ「そうだな～～ぁ カラ出勤と合わせれば1ヶ月は軽いしな
よ～～し、今年の夏はいっちょう行くかぁ～～ ハァ～、ハッハッハ」
ガキ「ワ～イ ワ～イ」
747:デフォルトの名無しさん
08/07/10 03:18:08
>>693
そこでなぜObject[]をGenericsで表現しないのか
748:デフォルトの名無しさん
08/07/10 03:18:51
>>730
C#と同じノリでいくか。
enumで出来れば十分だろ
749:デフォルトの名無しさん
08/07/10 22:55:31
>>747
複数の返値が型が違う場合を考えて。
750:デフォルトの名無しさん
08/07/10 23:12:29
>>749
それはT=objectで対処可能。
751:デフォルトの名無しさん
08/07/10 23:34:21
>>750
いや、・・・何かGenericsを勘違いしていないか・・・？
752:デフォルトの名無しさん
08/07/11 05:27:30
>>749
戻り値が違う場合？
俺の場合はその戻り値の型を同行する前に
自分で型を作って、二つの型に共通するスーパークラスを
作るにふさわしいかどうかを考えるがな。
そうはいかないときもあるが、そういうときは
根本的に設計上の問題があると考えられる。
デザインパターンを考慮するときはとくに。
753:デフォルトの名無しさん
08/07/20 00:18:11
JDK7 build31
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
754:デフォルトの名無しさん
08/07/21 16:51:54
>>752
(String , Map)
こんな二つの結果が帰ってくるときなら、Superclassも何も無いと思うが・・・
755:デフォルトの名無しさん
08/07/22 21:55:05
TextSS
756:デフォルトの名無しさん
08/07/23 07:28:02
URLﾘﾝｸ(mail.openjdk.java.net)
> Closures and XML support in Java 7 are unlikely.
だってよ、どーするよ。
757:デフォルトの名無しさん
08/07/23 08:28:01
んん？
unlikelyって・・・見込みがないってこと？
758:デフォルトの名無しさん
08/07/23 09:03:58
実装するのは思いのほか大変だってこと。
759:デフォルトの名無しさん
08/07/23 09:17:18
>>758
実装は URLﾘﾝｸ(www.javac.info) から取ってこれるが。
どっちかっつーと技術的な問題じゃなくて政治的な問題でしょ。
google も URLﾘﾝｸ(www.javac.info) みたいに及び腰だし。
760:デフォルトの名無しさん
08/07/23 09:48:43
実装という書き方が悪かったね。
今までのJava(Cの延長）からすればたいぶ異質なパラダイムを入れるのに抵抗があるので、思いのほか大変って意味。
761:デフォルトの名無しさん
08/07/23 09:57:18
そういうことかー
英語弱いんで助かりました。
762:デフォルトの名無しさん
08/07/23 09:58:55
>>760
パラダイムとか関係ないでしょ。
Javaにclosure入れるっていう根本方針に反対な人が多数派ってんならともかく。
763:デフォルトの名無しさん
08/07/23 10:00:18
> Java 7 itself is starting to seem unlikely ;-)
orz
764:デフォルトの名無しさん
08/07/23 10:05:11
genericsの時もやたらと遅れたし大規模に言語変更するときはJSRみたいな委員会型の組織だと動き鈍くて大変だよね
765:デフォルトの名無しさん
08/07/23 10:07:56
ぽんぽん尻軽に大規模な言語変更されても困るからしかたない
766:デフォルトの名無しさん
08/07/23 10:14:55
小規模な言語変更だとぽんぽん尻軽にやっちゃうんだけどね。
assert とか勝手に予約語に追加しやがるし。
767:デフォルトの名無しさん
08/07/23 12:43:43
assertが予約語で何か不満でもあるのか？
768:デフォルトの名無しさん
08/07/23 12:55:23
>>767
JUnitで使われてた assert って名前のメソッドが改名させられたのは有名な話。
enum って変数名使ってて泣いた奴も案外多かったりして。
769:デフォルトの名無しさん
08/07/23 13:33:48
それならC#の方が凄いんじゃないの？
770:デフォルトの名無しさん
08/07/23 13:38:08
enumは多かったな
771:デフォルトの名無しさん
08/07/23 13:40:21
>>768
ﾉｼ
772:デフォルトの名無しさん
08/07/23 15:00:16
>>755
URLﾘﾝｸ(www.vector.co.jp)
773:デフォルトの名無しさん
08/07/23 15:36:24
>>759
googleは時期尚早としか書いてないけど、
> 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がやりやすいかどうか、
良く確認してから決めたいと考えているのかな。
774:デフォルトの名無しさん
08/07/23 19:41:05
>>773
BGGA の初版から 2年、BGGA のver 5出てからもう 1年近くたってるし
未だに時期尚早ってのはなぁ……
Java7 から漏れるそうなのも、jsr166 に closure っつーか
function type 入れたくないよって事なんじゃねーかと邪推したくなる。
doug lea は function type 入れない CICE の提案者の一人だしなぁ。
775:デフォルトの名無しさん
08/07/24 00:08:41
さっさとScalaに移行しようぜ。Javaなんて、使ってられなくなるよ。
776:デフォルトの名無しさん
08/07/24 00:26:39
グルービーはもう廃れちゃったの？
777:デフォルトの名無しさん
08/07/24 00:27:15
あらま。delegate感覚で使えると期待してたのに。
まぁListenerの代替として使いたいって程度だから、
Swing Application Frameworkがあれば十分だけど。
代わりといっちゃなんだがOGNL式の静的チェック機能とか欲しい。
778:デフォルトの名無しさん
08/07/24 05:41:11
なんだこいつ？
779:デフォルトの名無しさん
08/07/24 08:01:33
>>777
その辺は JSR-305 さえ入ってくれれば
@Language("OGNL") とかできるようになるんじゃねーかと思うけど……
780:デフォルトの名無しさん
08/07/27 02:53:17
781:デフォルトの名無しさん
08/07/28 00:10:23
jakartaのなかから標準APIに取り込んで欲しいのは？
782:デフォルトの名無しさん
08/07/28 00:22:28
ない
783:デフォルトの名無しさん
08/07/28 00:28:42
俺もないなあ
標準APIは太りすぎだろ
784:デフォルトの名無しさん
08/07/29 16:07:43
EEやSEに突っ込んだら勝ちって競争になりつつあるからね。
土方プログラマ方面では標準化して統一してほしいだろうし。
785:デフォルトの名無しさん
08/07/29 16:24:35
いくら標準化しても、おまえじゃ使えないだろうな。おまえが使えるようになった頃には既に誰も使ってないだろうしw
786:デフォルトの名無しさん
08/07/29 17:15:22
jakarta、generics対応してないの多いからな
JDK1.3くらいのときはありがたかったものも今では必要ないとかかなりあるからね
787:デフォルトの名無しさん
08/07/29 17:35:02
正直、言語面の変化しか注目してない。
後は自分の使いたいクラスライブラリ使う。
788:デフォルトの名無しさん
08/07/29 17:44:27
JSR-203 の試験版。
URLﾘﾝｸ(download.java.net)
しっかし、これ
pfav.setOwner(fs.getUserPrincipalLookupService().lookupPrincipalByName("hoge"));
とか横に長すぎなんですが……
commons-nio が必要になる予感
789:デフォルトの名無しさん
08/07/29 17:49:12
メソッド名長くしすぎると、
Jakarta Commons VFSに負けちゃうかも…
>>774
CICEはクラス中心的でJavaっぽくていいんだけど、
これだけじゃ物足りないね。
790:デフォルトの名無しさん
08/07/29 17:52:12
それからDoug Lea先生は、JSR-166との絡みで、
control abstractionにまいっちゃってる可能性が…
そうするとBGGA, FCMに吸い寄せられるような
791:デフォルトの名無しさん
08/07/29 19:23:49
>>788
生APIってのはそんなもん
だからみんなファサード大量に容易するわけだ
生APIの場合は出来ないことが存在することがまずいわけで
多少のインターフェースの悪さは無視するのが普通かと
792:デフォルトの名無しさん
08/07/29 19:50:04
>>791
>>788 の例は、出来る出来ないの話じゃなくて、どっちかっつーとクラス構造(?)の話かな。
UserPrincipal extends java.security.Principal 使う必要があるんか？って話。
setOwner(String) でいいじゃんって思うんだけど。String じゃダメな理由あるんかな？
793:デフォルトの名無しさん
08/07/29 22:05:32
極端に言えば、BGGA以外は匿名クラスとあまり差はないし、ならクロージャいらないとの議論になりかねない。
BGGA自体も、関数言語指向の方向性は自然な姿だけど、controlのあれはビックリしたけどね。
なんだかんだ言ってサポートされるからブログとか追いかけて気にし過ぎだなｗ
794:デフォルトの名無しさん
08/07/30 00:15:33
>>793
ネストしたときのわけわからなさは異常
1つのメソッドのみのインターフェースを書くのがだるい人向けかな
業務系だと型そのものが大事ではなくてインターフェース名そのものが大事だから
あんまり使われないと思う
795:デフォルトの名無しさん
08/07/30 00:37:34
総称型はコンパイラ時の型安全のつもりだろうけど、インターフェイスの引数で使うとまったく違った使い方ができるし、
クロージャも同じように使ってるうちに全く想定外の使い方がでてくるんじゃないの。
interface Inte <T extends java.lang.Number>
{
int compareTo(T obj);
}
Inte<BigDecimal>だとobj.subtract(this)とかできる。
796:デフォルトの名無しさん
08/07/30 01:22:10
>>795
日本語でもうちょっとわかりやすく
797:デフォルトの名無しさん
08/07/30 01:33:57
言ってることはわかる気がするが
それなんか意味あるの？
798:デフォルトの名無しさん
08/07/30 02:18:49
>>784
> 土方プログラマ
が エア プログラマ にみえたので眼鏡を新調してくる。
799:デフォルトの名無しさん
08/07/30 05:00:44
>>798
おまえのそのメガネは高く売れる。
800:デフォルトの名無しさん
08/07/30 05:12:58
>エア プログラマ にみえた
正解です
801:デフォルトの名無しさん
08/07/30 09:18:27
>>788
これ 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 だとか名前の統一性なくなるからあんまし混ぜたくないんだよなぁ
802:デフォルトの名無しさん
08/07/30 12:00:59
こんなん見つけた。
URLﾘﾝｸ(blogs.sun.com)
module を言語全体のキーワードでなく文脈依存のローカルキーワードにしたいんだけど、例えば
class classname { module classname(){ throw new Error(); } }
って宣言があった場合、module型を返すメソッドなのか
module privateなコンストラクタなのか判別付かなくて悩ましいというお話。
互換性だけを考えると module型を返すメソッドにするべきなんだろうけど……
803:デフォルトの名無しさん
08/07/30 14:08:05
>>796
おまえの知能を疑うが、どこを日本語にして分かりやすくして欲しいんだ？
804:デフォルトの名無しさん
08/07/30 15:34:07
>>803
>>795のどこが不思議な使い方なんだ?
805:デフォルトの名無しさん
08/07/30 15:52:28
つ >>795にとって不思議
806:デフォルトの名無しさん
08/07/30 18:02:10
>>804-805
お前らの頭の中は不思議でいっぱい
807:デフォルトの名無しさん
08/07/30 18:42:40
>>768
あれは面倒くさかった。
ぜんぶassert()メソッドをassertEquals()やassertNotTrue
とかに変更する羽目になった
808:デフォルトの名無しさん
08/07/30 18:44:49
>>781
Log4jかな。あれを標準化したロギングAPIと統合して欲しい。
ライブラリ依存関係で混乱するから。
Commons Math、Commons Collections、Commons Configurations
も標準APIにいれて欲しい
809:デフォルトの名無しさん
08/07/30 18:48:12
>>786
CollectionsのGenerics対応はまだまだ遅いよな。
別ライブラリとしてGenerics対応されたやつがあるだけで
まだまだ時間かかりすぎる。
810:デフォルトの名無しさん
08/07/30 18:53:19
マ版でやってくれないか？
811:デフォルトの名無しさん
08/07/30 19:03:07
この話題はマ板じゃねぇだろ
812:デフォルトの名無しさん
08/07/30 19:44:09
>>802
単純型名で module型が使える場合は module型を返すメソッド、
そうでなければ module privateなコンストラクタってのはダメなんかね？
module型使ってる場合は module privateなコンストラクタを一切使えなくなるけど、
それはmodule privateな静的ファクトリメソッド使うなりして我慢してもらう方向で。
813:デフォルトの名無しさん
08/07/30 20:52:30
>>811
いや。十分にマ版ネタだと思うが。
814:デフォルトの名無しさん
08/07/30 21:04:53
moduleか
package名前空間使って
public package FacadePackage {
public class FacadeClass {
}
private class SomeClass {
}
private package SomePackage {
private class SomeClassB {
}
}
}
んなFacadeなパッケージを作れないだろうか。
UMLで登場したことがある「Facadeに相当するパッケージ」を
作れないかと期待。
今まではクラスレベルでしかできなかったことがパッケージレベルでも
出来ればと期待。
815:デフォルトの名無しさん
08/07/30 21:05:42
>>813
キーワードが増えてこまったこととか、CollectionsのGenerics対応とか、技術ネタだろ。マ板にもっていく必要性がわかんない。
816:デフォルトの名無しさん
08/07/30 21:51:13
技術ネタなんじゃなくて、おまえの愚痴でしかないようだが？
817:デフォルトの名無しさん
08/07/30 21:59:29
ネタとして次世代Javaではなさそうだが。
818:デフォルトの名無しさん
08/07/30 22:02:04
>>816
まぁ、落ち着けよ。
宿題やったか？早いうちに終わらせとけよ。
819:デフォルトの名無しさん
08/07/30 22:15:07
>>814
module で export package 指定できりゃそれで良いんじゃ？
820:デフォルトの名無しさん
08/07/31 00:52:21
>>818
早く死ねよ
821:デフォルトの名無しさん
08/07/31 01:48:01
>>819
それはC/C++のヘッダファイルと同じ運命を辿らないか？
できればimport宣言はそのクラス内ですませたい
822:デフォルトの名無しさん
08/07/31 03:08:13
>>818
ITドカタは来えろ
823:デフォルトの名無しさん
08/07/31 08:22:28
>>821
> それはC/C++のヘッダファイルと同じ運命を辿らないか？
ってどーゆー事？
「export うんたら」 はモジュール外から使えるクラス「うんたら」だけに制限する。
>>814 みたいな事は OSGi の Export-Package 使えばできるんじゃね？って思うんだが。
JSR-277 はそこんとこはクラス単位みたいだけど
それを パッケージ単位でもできるようにすれば良いだけのよーな。
824:デフォルトの名無しさん
08/07/31 10:03:56
>>801
Attributes.getBasicFileAttributes(path, true).isDirectory() までは短くなるな。
十分長いよーな気もするけど。
new File(path.toUri()).isDirectory() に比べても、まだ長いし。
825:デフォルトの名無しさん
08/07/31 10:12:33
>>812
そんな事するぐらいなら module を言語全体に影響するキーワードにした方がすっきりせんか？
変数名とかフィールド名にmoduleって名前使ってる人には泣いてもらう事になるけど。
826:デフォルトの名無しさん
08/07/31 11:51:29
SunにはJavaのコードからexeバイナリを生成するコンパイラの開発をしようという計画は無いんですかね
VM作ってるぐらいだからやる気になればそう難しくなさそうですが
本末転倒かな便利だと思うけど
827:デフォルトの名無しさん
08/07/31 11:59:58
>>826
スレ違いのレベルも下がったな。夏休みか。gcjでも食ってろ蛸。
828:デフォルトの名無しさん
08/07/31 12:13:47
>>826
スレ違いのレベルも下がったな。夏休みか。Visual J#でも食ってろ蛸。
829:デフォルトの名無しさん
08/07/31 12:47:13
粘着はそろそろ消えてくれないか
830:デフォルトの名無しさん
08/07/31 12:49:15
>>825
影響範囲がでかすぎる。
assertのときほどJavaはマイナーではないし、enumほどみんなに使われるわけでもない。
ほとんどの人が直接使わないのにキーワードにされたら、そりゃ怒るだろね。
831:デフォルトの名無しさん
08/07/31 13:05:12
>>830
moduleって名前使ってない人は怒らないから大丈夫。
それに列挙型よりはモジュール機能の方が使用頻度高いと思うが。
言語仕様汚れる方が将来の言語拡張の妨げになるから嫌って人も多いし。
832:デフォルトの名無しさん
08/07/31 13:09:29
>>802
そこに 2つ目の案として
class classname { module classname(){ throw new Error(); } }
はmodule privateなコンストラクタで、package privateなmodule型を返すメソッドは
class classname { package module classname(){ throw new Error(); } }
にしろって案が出てるけど、これも結構汚いよなぁ。
現実的ともいえるけど。
833:デフォルトの名無しさん
08/07/31 13:26:23
>>827
使いものになんねーだろあれ
834:デフォルトの名無しさん
08/07/31 14:11:32
gcjはclasspath使って書き換えるからそれが完了すれば5.0までいけるんだけどな。
835:デフォルトの名無しさん
08/07/31 14:52:33
もうウザイし、誰か相手してやれよ。
836:デフォルトの名無しさん
08/07/31 15:58:31
>>831
言ってることが良く分からないんだけど、どの言語仕様が汚くなるの？
837:デフォルトの名無しさん
08/07/31 16:56:07
>>836
全体にキーワード適用した方が言語仕様が単純に保てて汚れずに済むって話。
>>812みたいな小細工が汚れそのもの。
838:デフォルトの名無しさん
08/07/31 16:57:51
>>831
今後の言語拡張だけじゃなくてコンパイラの単純さ健全さバグの少なさにも影響してくるし。