[Java SE 7] 次世代Javaの動向 6 [dolphin]

1 ：デフォルトの名無しさん：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/

2 ：デフォルトの名無しさん：2008/01/03(木) 12:35:37

三行でなくてもいいので、
最近のJavaはどういう言語的要素を取り入れようとしているのか
簡潔に教えてください。

3 ：デフォルトの名無しさん：2008/01/03(木) 15:21:37

JDK7の大きな機能追加というと、
・クロージャ（ってMSVJ++のDelegateとどう違うのだか俺にはよくわからんのだが）
あとあとなんだっけ。

4 ：デフォルトの名無しさん：2008/01/03(木) 15:39:31

クロージャ追加って決定事項なの？

5 ：デフォルトの名無しさん：2008/01/03(木) 16:18:19

どうなったら「決定事項」なのか定義してくれ

6 ：デフォルトの名無しさん：2008/01/03(木) 16:38:12

>>5 おまえもウザイやっちゃなｗ
クロージャ追加は濃厚ってこと。

7 ：デフォルトの名無しさん：2008/01/03(木) 17:11:43

Duke に隠し子発覚。

8 ：デフォルトの名無しさん：2008/01/03(木) 17:35:27

>>6
総論としてのクロージャ追加に反対な人たちは少数派みたいだし、
クロージャ追加反対論の先頭に立つ人もいないから、
その意味ではクロージャ追加は濃厚。

ただし、各論としては、オレはアイツの提案のあれが気にくわないって感じでもめてる。
だからクロージャでもめたせいで1.7のリリースが遅れるとか
1.7の機能からクロージャが漏れるとかって事態はありうる。

9 ：デフォルトの名無しさん：2008/01/03(木) 18:26:26

例外処理まわりで使いやすくなる予定ってないのかな？

10 ：デフォルトの名無しさん：2008/01/03(木) 18:26:27

遅れるとか、そりゃないだろな。
BGGAだったか、{int a=>a+1;}; でまとまるよ。
その説得ってことだろうｗ
なんなら、ニールのブログに突撃してみたらどうだ？
このスレ的には勇者になれるしw

11 ：デフォルトの名無しさん：2008/01/03(木) 18:30:17

クロージャ
プロパティ
BigDecimalの演算子化
invokedynamic (JVM bytecode)

見た目で感じられて、濃厚なのはこれぐらいかな。
あとアノテーション拡張がどうとか。

12 ：デフォルトの名無しさん：2008/01/03(木) 18:33:25

個人的には
BigIntegerの演算子かも頼む

13 ：デフォルトの名無しさん：2008/01/03(木) 18:38:42

個人的には演算子オーバーロードをいい加減サポートして欲しい。
シンプルさを維持できないとかいう理由でその予定はないらしいが、
だったらString型のシンタックスシュガーもやめろよと思う。

14 ：デフォルトの名無しさん：2008/01/03(木) 18:53:51

>>13
C++とJavaは違うってことだｗ
また鼻息あらいようだなｗｗ

15 ：デフォルトの名無しさん：2008/01/03(木) 18:55:47

>>13
当然英語はできるんですよね？

16 ：デフォルトの名無しさん：2008/01/03(木) 19:02:55

限定的に使えるのと自由勝手に定義できるのじゃ全然違うべよ。
ALL OR NOTHING な発想は思考停止に等しい。

17 ：デフォルトの名無しさん：2008/01/03(木) 19:04:51

演算子オーバーロードはバグの温床

18 ：デフォルトの名無しさん：2008/01/03(木) 19:11:48

演算子オーバーロードが必要な人は大体は行列や複素数程度しか頭にないんだろうけど、
もしサポートしたら、いろいろすごい事になっちゃうよ。
とうか、もう違う言語かよってぐらいｗ

つまり
演算子オーバーロードが必要な人は大体は行列や複素数程度しか頭にないんだろうけど、

歴史的にはCのプリプロセスの悪夢と似てるんじゃないかｗ

19 ：デフォルトの名無しさん：2008/01/03(木) 19:14:07

それが必要なら、なんならリスト志向・関数志向の言語もやってみたら？

20 ：デフォルトの名無しさん：2008/01/03(木) 19:15:02

>>11
そこで出てる中で、仮にもJSRまでいってるのは
invokedynamic の JSR-292 と、
annotations on Java Types の JSR-308 かな。

プロパティは、JSR-303 とか JSR-295 とかあるけど、
構文糖の方は入るのかよくわからんし。

21 ：デフォルトの名無しさん：2008/01/03(木) 19:15:29

>>16
当然英語はできるんですよね？

22 ：デフォルトの名無しさん：2008/01/03(木) 19:18:12

>>20
"a" + "b" + "c"
"a".concat("b").concat("c")

よく使うし、普通は上でしょ。
理屈抜きで、プロパティもこれと同じようなことじゃないか。

23 ：デフォルトの名無しさん：2008/01/03(木) 19:19:14

フォートレス言語？

24 ：デフォルトの名無しさん：2008/01/03(木) 19:21:03

そーいや、Array syntax for collectionsはどーなったんだろ？
あれも演算子オーバーロードっちゃ演算子オーバーロードだよなぁ。

25 ：デフォルトの名無しさん：2008/01/03(木) 19:26:05

>>22
いや、プロパティの構文糖自体は簡単でもソースの互換性とろうとすると複雑なルールになるから面倒なんよ。

あと、beans仕様全体が性善説的な、みんなで守りましょうねって感じのルールなんで
Java言語仕様みたいな性悪説的なルールとして捉えると穴だらけなんで、そこら辺でも話はややこしくなる。

26 ：デフォルトの名無しさん：2008/01/03(木) 19:30:23

クロージャ
プロパティ
BigDecimalの演算子化
invokedynamic (JVM bytecode) ； JVMで複数の(スクリプト)言語サポートのこと
アノテーション・拡張
ジェネリクス

これだけあれば十分と思うけど。
これ以上が必要となる環境にいないしw
ということで演算子オーバーロードとかはもう過去の話ｗ

個人的には複素数も扱いやすいと数値計算・科学分野・学部生でも、
入門・お気軽プログラムできそうなんだけどね(JavaはGUIサポートしてる)。
個人的には、Javaは平面(GUI)を扱えるから複素数を押したい。
でも今はSUNは、デスクトップの方に力を入れて数値科学のほうは全然だしｗ

27 ：デフォルトの名無しさん：2008/01/03(木) 19:32:22

>>25
便利ならいいよ。俺らは策定する方じゃなくて、使うほうだしね。

28 ：デフォルトの名無しさん：2008/01/03(木) 19:33:50

そういやクラスのメソッドとしてではなく純粋な関数が入るかもって話はどうなったんだろ

29 ：デフォルトの名無しさん：2008/01/03(木) 19:36:20

>>27
策定する方も面倒だから簡単にはできねーだろーなっつー話。

プロパティ構文糖のプロトタイプ(?)がkijaroだったかに入ってるけど
あれ旧beansのプロパティと互換性ないでしょ。

30 ：デフォルトの名無しさん：2008/01/03(木) 19:36:58

>>28
function typeはモメてる。

31 ：デフォルトの名無しさん：2008/01/03(木) 19:37:14

>>25
また宗教ですか？

32 ：デフォルトの名無しさん：2008/01/03(木) 19:41:27

まだJDK1.7までは1年以上あるだろ。一回決定すると変更できないから、ちゃんと議論して、ちゃんと煮詰めて欲しい。これについては、納期とか速くしろとかとは別次元の話だろうな。

33 ：デフォルトの名無しさん：2008/01/03(木) 19:44:28

今年中に1.7出そうと思ったらもう1年もないし、
新機能追加を止めて、バグ取りに専念する期間も必要って事を考えたら
現時点でJSRすら出てない機能は相当遅いと思うけどなぁ。

34 ：デフォルトの名無しさん：2008/01/03(木) 20:57:08

演算子オーバーロードは
C++の入出力みたいに副作用を演算子で処理するのは違和感があるな。
Immutableなオブジェクトでないと使えないようにするとか……

35 ：デフォルトの名無しさん：2008/01/03(木) 22:21:45

Javaでの演算子のオーバーロード禁止は、シンプルさ確保が目的ではなくて、プログラマが乱用するのを防ぐために禁止にした。
言語仕様レベルでStringやBigDecimalを特別扱いしてやるのがJavaの回答(言語仕様策定者のみが定義できる)。

Javaの言語仕様はプログラマを信頼しない性悪説に基づいているので、自由にやらせろの人にとってみれば悪の化身のような言語にみえるだろうが、初級プログラマが世の中に多い以上こういう言語も必要だ。

Java と Java(Beta) みたいに言語を２つにして１つは初中級向け言語、１つは初中級者向け言語に機能優先で言語仕様を追加した中上級向け言語のようにしてみると、Javaにあの言語仕様入れろとかいう不満は少なくなるように思う。

36 ：デフォルトの名無しさん：2008/01/03(木) 22:49:26

>>35
それ、Scala使えって言われて終わりになるよーな。

37 ：デフォルトの名無しさん：2008/01/03(木) 23:02:54

Genericが結局1.4に入らなかったみたいに、7には積み残す方向で行くかもな。

38 ：デフォルトの名無しさん：2008/01/03(木) 23:47:11

>>33
知ったことではないけどねｗ

39 ：デフォルトの名無しさん：2008/01/03(木) 23:49:33

>>35
また宗教ですかｗ
分割するまでもなく、そういう人はruby, javascript でやってよ。
JVMでサポートされるし。
思うに君のような宗教家はJava宗教に向いてないだろうと思う

40 ：デフォルトの名無しさん：2008/01/03(木) 23:51:27

馬鹿にするなよ！
>>35は英語バリバリなんだじょ～

41 ：デフォルトの名無しさん：2008/01/04(金) 00:03:51

>>35のようなやつがプロジェクト率いたり仕様書作ったりしたら大変な事になりそうだなｗ考えただけでも恐ろしいｗｗ

42 ：デフォルトの名無しさん：2008/01/04(金) 00:07:14

>>35
当然英語はできるんですよね？

43 ：デフォルトの名無しさん：2008/01/04(金) 00:53:33

35氏の人気に嫉妬

44 ：デフォルトの名無しさん：2008/01/04(金) 02:09:04

>>35の言ってることが特に変だとは思えないけどな。
別の言語として、Javaのような何かが必要とは思わないけど。

45 ：デフォルトの名無しさん：2008/01/04(金) 08:08:11

Java SE 7 wish list
http://blogs.sun.com/ahe/entry/java_se_7_wish_list

46 ：デフォルトの名無しさん：2008/01/04(金) 11:51:23

英語はやっぱり面倒じゃじょ～

47 ：デフォルトの名無しさん：2008/01/04(金) 11:55:30

>>35は総突っ込みされてさぞ嬉しいだろうなｗ

48 ：デフォルトの名無しさん：2008/01/04(金) 16:08:56

英語出来なくても誰かが翻訳してくれるし。

49 ：デフォルトの名無しさん：2008/01/04(金) 16:10:22

>>35
はC, C++, C# の分化した歴史を話してるのだろうかと思った。

50 ：デフォルトの名無しさん：2008/01/05(土) 00:29:30

新参です
「当然英語はできるんですよね？」ってどういう経緯で始まったテンプレなんですか？

51 ：デフォルトの名無しさん：2008/01/05(土) 00:37:49

>>50
http://pc11.2ch.net/test/read.cgi/tech/1178925915/953-

52 ：デフォルトの名無しさん：2008/01/05(土) 01:03:32

>>51
さんくすおあらっと

53 ：デフォルトの名無しさん：2008/01/05(土) 10:18:45

英語で会話できるようになるのは、日本人の夢なのです！

54 ：デフォルトの名無しさん：2008/01/05(土) 20:13:52

クロージャでRAIIっぽく書けるらしいね

55 ：デフォルトの名無しさん：2008/01/06(日) 11:34:40

英語だとなんか緊張しちゃうし、別に日本語で十分じゃね？
APIの翻訳もリリースにあわせて出てるし技術書も翻訳でいいよ。
日常でも英語なくても困ってないし英語いらねー

56 ：デフォルトの名無しさん：2008/01/06(日) 12:09:13

>>13
>>35
当然英語はできるんですよね？

57 ：デフォルトの名無しさん：2008/01/06(日) 14:32:02

>>55
だいたいみょうちくりんな日本語だなあ、と思う文書は翻訳版だったことが多い。

58 ：デフォルトの名無しさん：2008/01/07(月) 00:08:39

>>56
粘着してる人つまんないからもういいよ

59 ：デフォルトの名無しさん：2008/01/07(月) 00:16:18

>>58
あたま大丈夫か？

60 ：デフォルトの名無しさん：2008/01/07(月) 00:19:54

>>58
新参乙

61 ：デフォルトの名無しさん：2008/01/07(月) 00:29:51

>>59
当然英語はできるんですよね？

62 ：デフォルトの名無しさん：2008/01/07(月) 00:31:22

粘着だろうと便乗だろうとつまらないことには同意しとく

63 ：デフォルトの名無しさん：2008/01/07(月) 01:08:19

ここ何日かで英語の重要性が分かった
頑張って勉強したんでみんなを追い越したよー
すごいだろー

64 ：デフォルトの名無しさん：2008/01/07(月) 17:06:13

>>63
先逝ったか？　南無阿弥陀仏。

65 ：デフォルトの名無しさん：2008/01/08(火) 11:41:54

英語なんかやっても会話ができるわけでもないしイラネー

66 ：デフォルトの名無しさん：2008/01/08(火) 17:23:26

コピペ、コピペっと。

>>65
当然英語はできるんですよね？

67 ：デフォルトの名無しさん：2008/01/08(火) 19:51:53

英語出来たら人生の難易度がガクッと落ちちゃいそうだから勉強しない。

68 ：デフォルトの名無しさん：2008/01/08(火) 23:58:59

やるなら韓国語でいいよｗ

69 ：デフォルトの名無しさん：2008/01/09(水) 00:15:42

http://www.nicovideo.jp/watch/sm1981743

この動画見ていたらdolphinとか笑えなくなってしまいました（笑）

70 ：デフォルトの名無しさん：2008/01/09(水) 15:19:47

英語出来なくても読めれば十分だしｗ英語が必要なときなんかはせいぜいその程度ｗ

71 ：デフォルトの名無しさん：2008/01/09(水) 20:03:45

おまいら違う言語の話題に熱心でつね。

72 ：デフォルトの名無しさん：2008/01/12(土) 23:32:34

パラメタに名前を付けてゴニョゴニョしたい場合ってアノテーション使うしかない？
public hoge(@Named("foo") int foo,@Named("bar") int bar)みたいに。

73 ：72：2008/01/12(土) 23:33:33

>>72
あっ、すいません。質問スレと間違えました。

74 ：デフォルトの名無しさん：2008/01/14(月) 15:53:35

Java SE 6 Update 4 リリースノート
http://java.sun.com/javase/ja/6/webnotes/ReleaseNotes.html

OGL: フラグメントシェイダーを使用して Linear/RadialGradientPaint を高速化
OGL: フラグメントシェイダーを使用して Convolve/Rescale/LookupOp を高速化
最近は色々な描画エンジンがシェイダー言語を使うようになってきたなぁ。

75 ：デフォルトの名無しさん：2008/01/14(月) 15:58:48

シャイダー言語ってどういう宇宙刑事語？

76 ：デフォルトの名無しさん：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

77 ：デフォルトの名無しさん：2008/01/18(金) 02:29:45

>>75
メタルダーだ

78 ：デフォルトの名無しさん：2008/01/18(金) 12:54:35

じゃあ一番は誰なんだ？

79 ：デフォルトの名無しさん：2008/01/18(金) 19:29:35

ナンバーワンダ

80 ：デフォルトの名無しさん：2008/01/22(火) 08:16:44

http://www.infoq.com/jp/news/2008/01/rubinius-multi-vm
Rubyですらこれができるようになるのに・・・

81 ：デフォルトの名無しさん：2008/01/22(火) 08:51:43

プロセス単位で起動すりゃ良いし、もしアレならクラスローダー単位をインスタンスと
見りゃ良いし、それってそもそも必要なの? メリットがよう分からん。

82 ：デフォルトの名無しさん：2008/01/22(火) 09:01:24

コレは便利　ＦｉｒｅｆｏｘをＩＥ化するマニュアル

Firefox 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:// ]を入力　[適用]　[ＯＫ]

83 ：デフォルトの名無しさん：2008/01/22(火) 11:05:54

>>81
それができるのはRubyだからというのはあると思うぞ。
JavaもAPI制限を加えれば、できるかもしれんが
スレッドのアプリごとの分離やそのリソース配分をどうするかっていう問題とか色々ある。
Zoneで使ったような解決方法でいいと思うんだけどね。

で、起動のオプションでMVMで動かすかシングルで動かすかを
指定できればいいのかな。

メリットは、ユーザが頭を悩まさずに使えるか、という部分だろ。
クラスローダ単位とかは、ちょっとテクニカルすぎる。

84 ：デフォルトの名無しさん：2008/01/22(火) 11:46:12

いや、だからそれを使うとなんか革命的な設計でも出来るわけ? 同一プロセス内で
複数のアプリケーションが独立して動くのはアプリケーションサーバで普通にやってるしょ。

テクニカルも糞も、パーティション(?)ごとに URLClassLoader 作ってそれぞれ main
となるスレッドに適当なクラスの main() か何かを呼び出すだけでしょ。
必要ならパーティション内でスレッドプールでも作ればいい。ライブラリならJakartaにも転がってるし。
まぁブートストラップクラスまで完全分離するのはちょっと無理だし、プロセス内で
仮想化ソフト並みのリソース管理システムでも構築できるってなら話は別だが。

意図が良く分からんので Java よく分かってない人が Ruby ﾏﾝｾｰしに来て失敗してる
ようにしか見えんのだが。

85 ：デフォルトの名無しさん：2008/01/22(火) 12:01:46

たぶん、あれば便利だよねっとことだろ。
リソース管理とか実現した後の話しだし、ならおまえは仮想化ソフト使えよ

86 ：デフォルトの名無しさん：2008/01/22(火) 12:01:50

MVMという話は、Java発祥だと思ってたんだが・・・・

87 ：デフォルトの名無しさん：2008/01/22(火) 12:05:26

なんだ、下らん。

88 ：デフォルトの名無しさん：2008/01/22(火) 12:54:42

ちょっと調べたが、今の Ruby は一つのプロセスにつき一つしか VM のインスタンスを
持てない。これは別プログラムから拡張ライブラリとして Ruby を呼び出しても同じ。
だから Apache の CGI として実行すると一つの VM で全てのリクエストを
こなす構成になり、素人が扱うには挙動がやっかいじゃのう、という話か。

JDK 1.2 以上の JNI 使っての Java 機能呼び出しは同一プロセスで複数 VM 起動もイケます。

--- 愁傷 ---

89 ：デフォルトの名無しさん：2008/01/22(火) 12:57:31

isolationって奴だよな。
http://en.wikipedia.org/wiki/Application_Isolation_API
http://jp.sun.com/company/Press/release/2008/0110.html

90 ：デフォルトの名無しさん：2008/01/22(火) 13:02:16

JavaのMVMが研究レベルから進まなかったのは、不正なメモリアクセスを行う
バグ持ちのネイティブコード呼び出しへの上手い対応が考えられなかった
からだと聞いたことがある。
Rubyもネイティブコードの呼び出しが出来る以上同じ問題にぶつかると思うけどね。

あるアプリがバグ持ちのネイティブコードを呼び出したとき、
JavaVM/RubyVMの管理するヒープを破壊されたとすると、
VMにホストされている全てのアプリが暴走するといった類の問題に
対する解答を用意することができるのかという所。

ちなみにネイティブコードの呼び出しが行えない携帯向けJavaVMでは、
実用化され既にMVMは普及しているレベル。
JSR 121,Application Isolation API Specificationだとかはどうなるんだろうねぇ。

91 ：デフォルトの名無しさん：2008/01/22(火) 13:10:21

それのゴールは Java VM の常駐なのかね? そういうことなら良さそうだな。

92 ：デフォルトの名無しさん：2008/01/22(火) 13:16:00

>>90
頑張って研究してくれよ

93 ：デフォルトの名無しさん：2008/01/22(火) 13:16:36

>>90
プロセス(タスク)に分離して、OSの保護機構を利用して、
それぞれのVMはプロセス(タスク)間通信で情報をやり取り。

94 ：デフォルトの名無しさん：2008/01/22(火) 13:29:16

>>93
素人が口だしするなｗ

95 ：デフォルトの名無しさん：2008/01/22(火) 13:58:41

>>80の元記事にそう書いてあんじゃね?
パイプうんぬんのところは未実装なんだろうけど。

96 ：デフォルトの名無しさん：2008/01/22(火) 21:46:41

妙なネイティブライブラリがクラッシュして全部巻き込まれるのはアプリケーションサーバでも同じだな。
それ対策のためにわざわざ RMI→JNI 経由して COBOL 呼ぶ設計をしたことがある。
IBM なんかそういうフォールトトレラントの研究はしてそうだが WebSphere にも実装されてないな。

97 ：デフォルトの名無しさん：2008/01/23(水) 02:58:02

>>96
やっぱりそうしたら良かったかなと、自作のプログラム相手に悩んでる。
いまんとこ20日くらいは持つんだが。
使っているのはあるライブラリのJava APIで、そいつがさらにJNIを...というパターン。

98 ：72：2008/02/07(木) 18:52:18

raw文字列のサポートの計画はないですか？
pythonみたいにr"\d"とか書ければうれしいです。

99 ：デフォルトの名無しさん：2008/02/07(木) 19:04:42

それの型って byte[] ?

100 ：デフォルトの名無しさん：2008/02/07(木) 19:36:19

Regular Expressionのrだと思ってた。
XMLリテラルも欲しいな。

101 ：デフォルトの名無しさん：2008/02/07(木) 20:25:40

"hoge".getBytes() は？

102 ：デフォルトの名無しさん：2008/02/09(土) 00:50:44

そういう問題じゃなくて

103 ：デフォルトの名無しさん：2008/02/09(土) 01:03:18

>>98
いまのところ聞かない。クロージャでもめてるし、JDK7じゃ望み薄かも？

104 ：デフォルトの名無しさん：2008/02/09(土) 19:18:14

>>98
それはサポートされたら地味に嬉しいな。
テンプレート的な文字列とか、正規表現書くとき悩まなくてすむ・・・・

105 ：デフォルトの名無しさん：2008/02/09(土) 21:01:22

あとソースコードにエンコード指定のメタデータ書けるようにしてほしい・・・

106 ：デフォルトの名無しさん：2008/02/10(日) 01:28:32

http://slm888.com/javac/
CICE ARM のプロトタイプだそうで。

クロージャ案の中で CICEが一番タイプ量多いんだよなぁ。
ぶっちゃけCICEだけだったら匿名クラスがあるから要らんような。
ARMは欲しいけど。

107 ：デフォルトの名無しさん：2008/02/10(日) 16:36:05

>>105
それは欲しい。ソースコードが単体で完結せず、エンコーディングというメタデータが必要なのは痛い。

108 ：デフォルトの名無しさん：2008/02/10(日) 16:40:52

UTF-8 で統一しとけよ…

109 ：デフォルトの名無しさん：2008/02/10(日) 17:24:40

>>106
List<String> list を大文字小文字区別せずに整列させる場合だと、こんな感じか。

無名クラス：
Collections.sort(list, new Comparator<String>(){ public int compare(String s1, String s2){ return s1.compareToIgnoreCase(s2); } });

CICE：
Collections.sort(list, Comparator<String>(String s1, String s2){ return s1.compareToIgnoreCase(s2); });

FCM：
Collections.sort(list, #(String s1, String s2){ return s1.compareToIgnoreCase(s2); });

BGGA：
Collections.sort(list, {String s1, Strings2 => s1.compreToIgnoreCase(s2) });

110 ：デフォルトの名無しさん：2008/02/10(日) 17:46:12

>>108
javacもIDEも、デフォルトのエンコーディングが環境依存だし
ソースファイル単位で指定できればかなりありがたいんだけど…

packageの次あたりに
encoding "UTF-8"
みたいに書いて指定出来るといいのになあ。

111 ：デフォルトの名無しさん：2008/02/10(日) 17:49:36

>>109
どれも汚ｯﾀﾈｰのな。

112 ：デフォルトの名無しさん：2008/02/10(日) 18:02:48

>>109
面白いけど、どれもパッとしない
Javaらしい気持ち悪さ

113 ：デフォルトの名無しさん：2008/02/10(日) 18:05:58

Logging API の時みたいに間に泡ねーとかそういう理由で適当にでっち上げてもらいたくないね。
ライブラリレベルの話じゃないんだし。

114 ：デフォルトの名無しさん：2008/02/10(日) 18:11:35

>>113
クロージャの事を言ってるなら、
もめてるのは議論してどうこうできるレベルの話じゃないような。
「Javaらしさ」なんて、そんなもん個人個人で違うんだから議論にならんし。

時間かければどうにかなるもんじゃないと思うが。

115 ：デフォルトの名無しさん：2008/02/10(日) 18:12:31

そもそも時間かけたはずのgenericsがあの体たらくだしな

116 ：デフォルトの名無しさん：2008/02/10(日) 18:17:37

もうHaskell風に(\s1,s2 -> s1.compreToIgnoreCase(s2))でいいよ
Stringくらい型推論しろ

117 ：デフォルトの名無しさん：2008/02/10(日) 18:32:46

そうか、そうだな。時間かけて話し合えば良い物できるできるというものでもなかったな。
声のでかい順に嗜好を取り込んだ最小公倍数的仕様が最良になるとは思わないし。
逆にセンスのある一人の天才が作った方がシンプルで良い。

118 ：デフォルトの名無しさん：2008/02/10(日) 18:39:00

>>116
C#でも仮引数型の型推論してくれたような。

119 ：デフォルトの名無しさん：2008/02/10(日) 18:43:23

仮引数型の型推論は、後付けで導入できるんだったら後回しでもいいような気もする。
他の部分で型推論を導入する際の一貫性みたいなもんもあるし。

120 ：デフォルトの名無しさん：2008/02/10(日) 21:54:02

Javaもサーバだけじゃなく一般的になってきて、変なのまでJavaを使うようになってしまったんだな。
変な奴やC#かC++に行ってくれ。

121 ：デフォルトの名無しさん：2008/02/10(日) 22:09:26

>>120
さようなら、変な人。。

122 ：デフォルトの名無しさん：2008/02/10(日) 22:26:23

順調にJavaも巨大になってきてるね。
まあいじくられる対象ってのはそういうもんだよね。

123 ：デフォルトの名無しさん：2008/02/10(日) 22:32:44

ただ大勢で規格を開発された言語ってのは、
あまりいい感じにならないんだな。
PL/1, Ada, Common Lispなど。
規格管理だけならいいんだけど。

124 ：デフォルトの名無しさん：2008/02/10(日) 23:28:46

そりゃこういう連中は総じて自分の業績と功名心の下心でやってるんだから仕方がない。
スタンダードさえ勝ち取れば、中身が多少糞なのは「解釈の問題」とでも言っておけば
後世まで評価されると言うことを彼らはよく知っている。

125 ：デフォルトの名無しさん：2008/02/15(金) 09:54:54

>>123
重要ところが抜けているけど、javaは規格じゃなくてあくまで企業やjavaを活用する団体が管理している。
ISOとか関係ないから、それでは例えが悪くそもそもそれらの言語とは比べられない。
おまえは言語使用とライブラリは分離されているとか、そんなところも見えてないだろｗ

126 ：デフォルトの名無しさん：2008/02/15(金) 10:29:22

（　ﾟдﾟ）ﾎﾟｶｰﾝ

127 ：デフォルトの名無しさん：2008/02/15(金) 20:15:06

>>126
大事なところ指摘してるのが分からないんだね。低脳さんｗ

128 ：デフォルトの名無しさん：2008/02/15(金) 20:26:54

悪いが俺も >>125 は勝手に話を広げてるようにしか見えないわけだが。

129 ：デフォルトの名無しさん：2008/02/15(金) 20:40:23

規格(standard)ではなく仕様(specification)と言えというのならまだわかる。

130 ：デフォルトの名無しさん：2008/02/15(金) 21:29:54

話は変わるがJavaはSEやEEにどの機能を入れるかというJSRがあるのがいいな。
EE6の場合だとこれだけの機能を追加するのにいくらかかるという資産までしてるみたいだし。

131 ：デフォルトの名無しさん：2008/02/15(金) 21:35:36

資産(asset)ではなく試算(trial calculation)と言えというのならまだわかる。

132 ：デフォルトの名無しさん：2008/02/15(金) 23:31:20

揚げ足鳥ってこういうことになっていつも非生産的な行為でしかない。非生産的なジャヴァ言語と同じ。

133 ：デフォルトの名無しさん：2008/02/15(金) 23:31:55

なんというこじ付け

134 ：デフォルトの名無しさん：2008/02/15(金) 23:41:16

>>129
>>123-127のレスには「仕様」のことは触れてないようだが、
どこからそんな指摘が出来るんだ？
ところで英語で言えばカッコいいなどと思ってるなら考え直した方がいいだろう。

135 ：デフォルトの名無しさん：2008/02/15(金) 23:42:51

もちろん英語はできるんですよね？

136 ：デフォルトの名無しさん：2008/02/15(金) 23:44:42

>>125みたいな変人はどこにでもいるから。

137 ：デフォルトの名無しさん：2008/02/15(金) 23:52:25

とっても口惜しそうだねｗ

138 ：デフォルトの名無しさん：2008/02/15(金) 23:53:55

若干一名な。

139 ：デフォルトの名無しさん：2008/02/15(金) 23:54:09

（´･∀･`）ﾀﾞﾖﾈｰ

140 ：デフォルトの名無しさん：2008/02/15(金) 23:56:46

くだらないことをいつまでも続けるのがねらーの悪いとこだな
アダルトチルドレンが多すぎ（古館的な意味で）

141 ：デフォルトの名無しさん：2008/02/15(金) 23:58:12

↑アダルトチルドレン（古館的意味）とは、正しくおまえのことだな

142 ：デフォルトの名無しさん：2008/02/15(金) 23:59:39

クロージャーの議論で、ゴズリンは愚痴ってるけどでもやる気みたいだけど、結局クロージャはどうなるの？

143 ：デフォルトの名無しさん：2008/02/16(土) 00:02:17

>>141
こういうループ野郎がねらーそのもの

144 ：デフォルトの名無しさん：2008/02/16(土) 00:03:49

（´･∀･`）ﾀﾞﾖﾈｰ

145 ：デフォルトの名無しさん：2008/02/16(土) 00:10:54

若干一名って、おまえの思い込みなだけじゃないのかｗ

146 ：デフォルトの名無しさん：2008/02/16(土) 00:17:17

（´･∀･`）ﾀﾞﾖﾈｰ

147 ：デフォルトの名無しさん：2008/02/16(土) 00:18:37

とっても口くやしそうなのが若干一名います。

148 ：デフォルトの名無しさん：2008/02/16(土) 00:23:00

（´･∀･`）

149 ：デフォルトの名無しさん：2008/02/16(土) 00:24:20

（´･A･`）ﾀﾞﾖﾈｰ

150 ：デフォルトの名無しさん：2008/02/16(土) 00:27:54

>>125の人気に嫉妬。

>>142
ゴスちゃん一人がそんな影響力あるわけじゃないから。
言語開発者であった初期だけでなく、
Javaの方向性に大きな影響を与えたけど、
もうそろそろいいでしょ。

151 ：デフォルトの名無しさん：2008/02/16(土) 00:30:28

>>142
派閥が出来てる状態で言語仕様に深く関わる機能を盛り込めはしないでしょう。

てかサーフィンしてたらSE7にEJB3が追加されるってブログを見つけた。
Webサービスじゃなくて何故にEJB？

152 ：デフォルトの名無しさん：2008/02/16(土) 00:54:37

というか、いまどき「サーフィンｗ」ってなに？

153 ：デフォルトの名無しさん：2008/02/16(土) 00:56:18

また沸いてら

154 ：デフォルトの名無しさん：2008/02/16(土) 01:10:52

>>151
クロージャに限定すれば、BGGAとかの派閥といってもクロージャの書き方というかリテラルが少し違う程度だろ。
Genericsのようにどこまでテンプレート・プログラムを認めるかと同様に、
クロージャをどこまで広げるかの考え方はあるだろう。
しかし、それを議論していても結局は内部クラス（匿名クラス）でいいのかの議論に戻ってしまうし
とすれば、派閥とかいってもリテラルが簡単か否かの違いでしかない。

それとゴズリン（のUNIXでの貢献も含めて）のそのセンス自体がそのままJavaの思想やセンスになっていると思うんだが？
C#はたいした手間でもないのに何でもリテラルして言語仕様にしたりするけど、正直キモイ。
やっぱりMSはいつまでもハンガリアンだしｗ

155 ：デフォルトの名無しさん：2008/02/16(土) 01:15:32

派閥まで出来とるのか。
ブラウザで踊ってるデューク見て感動していた頃の古き良き時代が懐かしい。

156 ：デフォルトの名無しさん：2008/02/16(土) 01:20:22

Javapolis(source)の調査結果は賛否両論であった。
30人の参加者はCICEに賛成し、
BGGA/FCM+JCAは２４人の賛成を得た。
そして、19人が変更しないことを選んだ。

http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java

157 ：デフォルトの名無しさん：2008/02/16(土) 02:25:40

そのは記事以前も見た気がするけど、記事の本人（外人）自体が「Javaらしさ」を
追求しすぎてバイアスがかかってるってことに気がついてない。
クロージャの話なのにScalaとか勧めてるし、多分バカなんだろ。

クロージャってのは中途半端な内部クラスの設計を、さらに拡張して完成させる程度でしかないだろうな。
C++のtemplateかと思ってたらgenericsは思ってたのと全然違ってたし、
クロージャもアレコレ議論するのはオープンでイイが、同じくそんな感じに落ち着くんじゃないか？
うまくいけばゴズリンが大好きなemacs lispにまでもっていければってところ。

158 ：デフォルトの名無しさん：2008/02/16(土) 02:28:00

もういっそヒアテキストで他言語埋め込めるようにすりゃ全て解決するだろ。

159 ：デフォルトの名無しさん：2008/02/16(土) 02:52:13

char c= "abc".charAt(1);

int z= {int x, int y => x+y}.invoke(2,3);

で、BGGAはStringリテラルと似たようなもの。
CICEは匿名クラスが少し短縮してある程度でしかない。

new Thread(new Runnable() {
public void run() {foo();}
}).start();

new Thread(Runnable(){ foo(); }).start();

160 ：デフォルトの名無しさん：2008/02/16(土) 02:53:10

>>158
全くイメージできないんだけど、どういうこと？

161 ：デフォルトの名無しさん：2008/02/16(土) 02:58:08

どちらにせよライブラリレベルじゃ不都合だったり出来なかったことが
可能になるわけじゃないから、匿名内部クラスを普通に使ってる人間には
言語汚染にしか見えんのー。

162 ：デフォルトの名無しさん：2008/02/16(土) 03:04:54

>>157
Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahe　の４人が
進めている下記のクロージャ仕様(BGGA)ならまともなものだと思うぞ。
http://www.javac.info/closures-v04.html

これがjava7の仕様の一部となることを願うんだ！

163 ：デフォルトの名無しさん：2008/02/16(土) 03:07:36

int x = (Integer)new Function("JavaScript", "alert('hello, world');return 100;").exec();

とかで十分だと思うんだ俺…

164 ：デフォルトの名無しさん：2008/02/16(土) 05:18:51

別にｲﾗﾈｰ気もするんだが、自分がいる間に目玉商品機能を作りたいもんなんかね、中の人的には。

165 ：デフォルトの名無しさん：2008/02/16(土) 08:45:46

要るわ。>>162がいい。

166 ：デフォルトの名無しさん：2008/02/16(土) 12:26:06

そろそろLegacyJavaとか言って1.4をメンテし始めて欲しいのだが

167 ：デフォルトの名無しさん：2008/02/16(土) 12:29:51

>>163
それは、普通に使われるとセキュリティーに穴が開くからヤバイと思う。

168 ：デフォルトの名無しさん：2008/02/16(土) 12:48:06

Java 6 からは Scripting API というものがあってだな（ｒｙ

169 ：デフォルトの名無しさん：2008/02/16(土) 13:33:31

finalと匿名クラスのシンタックスシュガーを用意するだけだよね？
foreachみたいに特定のインタフェースを持ったオブジェクトに適用されるような。

そうなるとJVMがインタフェースを登録するタイミングが気になる。
JEEでClassNotFoundExceptionをやらかす人を増やす仕様だったらどうしよう。
何百個というインタフェースをjava.lang.closureに放り込んで
ブーストラップクラスローダーでロードさせとくとかそういう仕様？

170 ：デフォルトの名無しさん：2008/02/16(土) 14:47:57

クロージャをイベント処理とかでよく使う匿名クラスの延長と見るか、
全く新しいパラダイムと見るかじゃないか？
全く新しいといいつつも、
{void => void} .equals( new java.lang.Function() {
public void invoke(){}
}
と同じことを仕様として入れたいのだろうけど。（多分）
内部クラスあるけど、GUIだといつも使うし<... onclick="callback()"> のように書ければいいよねだろ。
大元の発想は。

"abc".equals(new String("abc"))
と同程度なことが実現できるメソッド・バージョン。
クロージャを何に活用するかは議論してるみたいだし、知らん。

171 ：デフォルトの名無しさん：2008/02/16(土) 15:08:49

>>168
Java 6が出た当初はjsとの連携なんていらんだろと思ってたけど、最近はjsがお気に入り☆
java.nio とか当初はjava.ioあるし、いらんと思ってたけど、これもなかなか。
内部クラスあるし今はクロージャなんて全くいらんとかかも知れんが、クロージャも同じく「なかなか」になるのかと思う。

172 ：デフォルトの名無しさん：2008/02/16(土) 15:42:56

リリース予定は今年でおｋ？

173 ：デフォルトの名無しさん：2008/02/16(土) 15:46:38

JSRが提出されるのはSE7のが先じゃないの？
BGGAもv0.5とかなってるし、間に合わない気が

174 ：デフォルトの名無しさん：2008/02/16(土) 22:42:22

まったくクロージャを策定するのは苦労じゃ。

175 ：デフォルトの名無しさん：2008/02/16(土) 22:46:25

そうだね

176 ：デフォルトの名無しさん：2008/02/16(土) 23:07:33

＿＿＿＿　　　　　　　　　　　　　　CICE版
|← reject|　　 BGGAの中の人　 Closure　　ユーザー
.￣.||￣￣　　　　　　　　┗(^o^ )┳(｀Д´)┳(^o^ )┛≡＝-
　　||　　　　　　　　　　　　┏┗　　 ┗┗　　┏┗　≡＝-
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

177 ：デフォルトの名無しさん：2008/02/23(土) 00:23:23

>>156
http://www.java.net/pub/pq/196
こっちの投票だと CICE 3.9%、BGGA 42.7%で 10倍も差がついてる。
javapolisだと、josh blochの公演があったからそれに引きずられたんだろね。
公演前は 2:1 でBGGAの方が投票多かったって書いてあるし。

派閥っても、公演一回でひっくり返るレベルなのよね。

178 ：デフォルトの名無しさん：2008/02/23(土) 03:01:15

まあ、長く使わんと手に馴染み具合が分からんですよねぇ

正直、CICEは今の匿名クラスに比べて何がメリットかよく分からないので却下したい。

BGGAは、表記がごちゃごちゃして新しい構造が入ってくるので
ぱっと見た目、1.4世代の人が見たらもう分け分からんことになりそうだな、という不安。
まあ、そう言う人は十分Genericsでも分からないコードになってるのかも知れないけど・・・
この表記ならついでに複数返り値もサポートして欲しい感じ。

FCMは、Cとかの関数ポインタに似てるのですっきりしてていいかもしれない。
今のところ一番分かりやすいけどthis#hogehoge()とかしたときに
実行コンテキストが見た目的に予測しにくいな。

ただ、>>106 のARMは欲しい。
こういう分かりやすくなる変更は歓迎したい。
Genericsは訳分からなくなったし。Closureには同じ轍を踏んで欲しくない・・・・

179 ：デフォルトの名無しさん：2008/02/23(土) 09:10:53

ARMよりは、BGGAのcontrol invocation syntax使える方が嬉しいけど。
ARMってjava.io.Closeableとか、java.util.concurrent.locks.Lockとか
特定のinterface実装してないと使えないみたいだし。

FCMにもJCAあるけど、これはライブラリ側の書き換えが必要になるんかな

180 ：デフォルトの名無しさん：2008/02/23(土) 23:01:24

匿名クラスを少しいじってみたけど、結局GUI辺りとか、イベントでしか使わないよ。
だからゴチャゴチャして分からなくなるとかはお門違いだと思った。
BGGAとかFCMとか表記やタイプ量が違うだけど、内部では匿名クラスと全く変わんないし。
確かにクロージャは、イベントを超えてラムダみたいに何か活用するなら今までと全く違うから抵抗あるのかもしれない。

必要ないと考えてる奴らはイベント程度でしか見てないし、
イベント以外の活用が見出せないだけじゃないか？

匿名クラスを少し使ってみたら、新しいクラス生成式
（クラス生成リテラル）ってところだなと感じた。

181 ：デフォルトの名無しさん：2008/02/23(土) 23:02:49

匿名クラスと比べてみたら、新しい

182 ：デフォルトの名無しさん：2008/02/23(土) 23:07:22

内部匿名クラスは、やっぱりjdk1.0のイベント処理方法の不満から解決策として出てきたんだし、
匿名クラスの設計（や表記方法）が中途半端というのはよく分かる。
本心としては、昔は急いでたから匿名・関数生成リテラルまで設計してなかったこと
についての後始末ってとこなんじゃないか？

183 ：デフォルトの名無しさん：2008/02/23(土) 23:20:19

でもたいして変わらないものにしかならなさそうなんだけど。

184 ：デフォルトの名無しさん：2008/02/23(土) 23:33:17

そもそもクロージャ自体「使わなくてもいい便利なもの」扱いしてる時点で「匿名クラスと大して変わらないもの」あつかいされるのは仕方ないんじゃないか。
匿名クラスのシンタックスシュガーレベルの扱いじゃなくて、通常のメソッドがクロージャの簡易構文になってるぐらいでないと意味ない気がする。

185 ：デフォルトの名無しさん：2008/02/24(日) 00:18:33

>>182
匿名クラスの設計も表記方法も完成されてると思うよ。
単にタイプ数が多くなるから面倒くさいだけで。

匿名クラスを弄ったCICEが進化だとか、
CICEで匿名クラスは完成された、とか言うなら話は別だけど。

186 ：デフォルトの名無しさん：2008/02/24(日) 07:18:15

匿名クラスは匿名クラスでいいが、
クラスである必要のないところにはクロージャを使いたい。
クラス至上主義は要らない。関数は関数だ。

187 ：デフォルトの名無しさん：2008/02/24(日) 07:21:55

匿名内部クラスより (数値の上でだけでも) パフォーマンスが良いとかあればまだ良いんだけどね。

188 ：デフォルトの名無しさん：2008/02/24(日) 10:28:49

それが無いと困る場合というのが明確でない機能は
追加せんでもいいと思うんだが。
ジェネリクスやプロパティまでは理解できたが、
クロージャは必要性がよくわからんな。

189 ：デフォルトの名無しさん：2008/02/24(日) 14:09:45

JDK1.6のコンカレント関連のFeature<T>とか見たときに、いい加減第一級の関数型なしに匿名クラスでエミュレーションするのは苦しいだろうと思ったのだが、おまえらはどうだ？

190 ：デフォルトの名無しさん：2008/02/24(日) 14:27:15

もう JCP は勝手に別の言語でも作っててもらいたいんだが。

191 ：デフォルトの名無しさん：2008/02/24(日) 14:33:28

>>189
禿同。
何でもクラスと言われたSmalltalkより酷いことになってる。
まさにクラス馬鹿一代。> Java

192 ：デフォルトの名無しさん：2008/02/24(日) 14:44:48

>>189
苦しいというほど頻繁に使われるシーンが思い浮かばない。
Threadとかもあるし、俺はこの程度なら言語仕様を汚してまで
導入する意義は薄いと思うな。

193 ：デフォルトの名無しさん：2008/02/24(日) 14:49:35

汚れない

194 ：デフォルトの名無しさん：2008/02/24(日) 15:54:36

>>189
Future<V>はクラスで適切だと思うけど。
Callable<V>インターフェイスを実装した匿名クラスを書くのが面倒なので
クロージャ使わせろという話と勘違いしていない？

あと、BGGAの block.invoke(args) って記法を block(args) って書けるように
してほしいなぁ。

まあ、RubyのクロージャもWikiPediaによると
># 後に必要になった時点でクロージャを呼び出す。
>@block.call("John")
># 表示:"Hello, John!"
と書いてあって、RubyもJavaのBGGAと同じくあくまでクロージャを
オブジェクト扱いしているっぽい。
なので、Rubyのblock.call(args) みたいに、クロージャの呼び出しは
オブジェクトのメソッド呼び出しと同じように書くのが普通なのかもしれんけど。

195 ：デフォルトの名無しさん：2008/02/24(日) 16:06:07

> あと、BGGAの block.invoke(args) って記法を block(args) って書けるように
おれもして欲しい。

けどクロージャができるまでは、メソッドの名前空間と
フィールド/変数の名前空間で分かれてたのに、
closure(arg)を許すと、区別つかなくなるから難しいんじゃね？

196 ：デフォルトの名無しさん：2008/02/24(日) 16:13:21

>>192
ぶっちゃけ、プロパティ導入の方が言語仕様が汚れる。
>>195の反対の理屈で、いままでメソッドだったものが
フィールド/変数の名前空間使うことになるから。

197 ：デフォルトの名無しさん：2008/02/24(日) 16:27:53

プロパティはほんと汚れるって感じするわ。便利だけどw

198 ：デフォルトの名無しさん：2008/02/24(日) 16:33:31

プロパティがないとRADサポートできない。

199 ：デフォルトの名無しさん：2008/02/24(日) 16:47:13

「どっちがより汚いか」なんて議論しても意味ねーw
新しい表記、文法の導入はどっちにしても「汚れる」ことに変わりない。
重要なのはそれを許容するだけのメリットがあるかどうか。

200 ：デフォルトの名無しさん：2008/02/24(日) 16:50:42

クロージャでもBGGAの場合は、RAIIっぽい事ができるってメリットあるけど、
プロパティは基本的にタイプ数が減るだけ。

201 ：デフォルトの名無しさん：2008/02/24(日) 16:52:58

>>199
汚れる程度の問題もあるんだよ。
プロパティ導入は下手するとソース互換性破壊するし。

202 ：デフォルトの名無しさん：2008/02/24(日) 16:53:53

コンポーネント志向にはプロパティが必要。

203 ：デフォルトの名無しさん：2008/02/24(日) 16:55:26

beansのプロパティで我慢

204 ：デフォルトの名無しさん：2008/02/24(日) 17:07:46

>>201
バイナリ互換性じゃなくてソース互換性？
「下手すると」って書いてるけど、どの案でどういう問題が？

205 ：デフォルトの名無しさん：2008/02/24(日) 18:03:08

>>204
あるクラスにプロパティ hoge と、フィールド hoge があった時に、
識別子 hoge で、フィールドとプロパティどっちアクセスすんの？って話。

プロパティ hoge の宣言と、フィールド hoge の宣言を排他にすりゃ問題ないけど
beans のプロパティ hoge と、フィールド hoge は共存できてたわけで、
安易に排他にするとソース互換性を破壊する。

アクセスレベルのルールをちゃんと考えれば互換性たもてるかもしれんが、
失敗すればフィールドアクセスのつもりがプロパティアクセスになったりしてソース互換性破壊する。
頑張ってアクセス時のルールで互換性維持したとしても
プロパティ hoge を継承クラスのフィールド hoge で隠蔽できるようになったりする。

206 ：デフォルトの名無しさん：2008/02/24(日) 18:26:02

排他にすりゃいいし、フィールドで隠蔽できないようにすりゃいい。
というか、draft3はそういう案じゃなかったか？

で、それが「安易に排他にする」ことだとして、そこで発生する問題は何？

207 ：デフォルトの名無しさん：2008/02/24(日) 18:30:18

>>206
標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。
beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。

っつーか、draft3 ってどれの事いってるん？

208 ：デフォルトの名無しさん：2008/02/24(日) 19:00:33

これね。
http://docs.google.com/View?docid=dfhbvdfw_1f7mzf2

>標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。

そこであらかじめ定義されたプロパティと同名のフィールドをサブクラスで
定義しなきゃならないケースというのが想像できないんだけど？
もしそれが問題になるんなら、親クラスで定義されるのがプロパティじゃなくて
フィールドでも一緒じゃね？

>beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。

beansと関係ないからこそソース互換性を保てるわけなんだが。

209 ：デフォルトの名無しさん：2008/02/24(日) 19:48:02

>>208
自前のクラスで、標準APIのクラス Hoge を継承する SubHoge に、
フィールド hoge が宣言されてるとする。
これは既存のソースでプロパティ導入前にはなんの問題もないけど、
プロパティが導入されて、標準APIのクラス Hoge にプロパティ hoge が後付で導入され、
おまけにプロパティとフィールドが排他だとなると、ソース互換性が破壊されるわけ。

フィールドは隠蔽されるだけだし、最初から存在するルールだからソース互換性は破壊されない。

210 ：デフォルトの名無しさん：2008/02/24(日) 19:59:01

標準API ：
class Hoge{ abstract Hoge getHoge(); }
ユーザ側：
class SubHoge extends Hoge{
　Hoge hoge;
　Hoge getHoge(){ return hoge; }
}
で上手くいってたのに、
プロパティ導入して、標準APIが
class Hoge {
　abstract Hoge getHoge();
　abstract property Hoge hoge;
}
とかに変わると、SubHoge はコンパイル通らなくなるわな。

211 ：デフォルトの名無しさん：2008/02/24(日) 20:04:42

後付けでプロパティ追加なんてしなきゃいいじゃん。
これができないとどういう場合に困るの？

212 ：デフォルトの名無しさん：2008/02/24(日) 20:12:09

>>208
あと、beansとの互換性を維持する場合の問題は別にあって、
同名のプロパティが言語仕様上は共存できるとかね。
例えば
interface Hoge {
boolean isHoge(); void setHoge(boolean b);
Hoge getHoge(); void setHoge(Hoge hoge);
}
は、言語仕様上は問題ない。
だけどプロパティとしては同名プロパティが複数あるので曖昧になる。
beans仕様は厳密じゃないから、どっちを優先的にプロパティにするかとか、
実は同名プロパティを複数持ったbeansは不正なのか、みたいな事を記述してない。
java.beans.Introspector が決める事になってるみたいだけど、
これもブラックボックスで振る舞いは文書化されてない。

で、beansと互換性のあるプロパティを言語仕様に導入しようとしたとき
Hoge hoge;
System.out.println(hoge.hoge);
とかなったとき、getHoge() を呼ぶべきか isHoge() を呼ぶべきか？
はたまた同名プロパティは宣言できないようにすべきか？みたいな問題が出てくる。

まぁ、こーゆーのが現実に問題になるケースは少ないと思うけど
言語仕様上はきっちり決めとかないといけないから。

213 ：デフォルトの名無しさん：2008/02/24(日) 20:33:45

みんなきちんとIntrospectorを使っているんならまだましだけど、
勝手にやっちゃってるフレームワークが氾濫しているのも問題だよな。

214 ：デフォルトの名無しさん：2008/02/24(日) 20:41:35

今時プロパティのない言語は時代遅れ。

215 ：デフォルトの名無しさん：2008/02/24(日) 20:44:49

get/setをエディタが補う時代にプロパティとかいらんだろ
でもプロパティってバインド機能があるんだっけか

216 ：デフォルトの名無しさん：2008/02/24(日) 20:48:48

追加はしてくれるけど、消したり隠したりしてくれないんだよな。

217 ：デフォルトの名無しさん：2008/02/24(日) 21:27:05

正直クロージャすらない言語は時代遅れ

218 ：デフォルトの名無しさん：2008/02/24(日) 22:29:55

func.invoke(20)をfunc(20)にするのだけど、確かに見た目と意味が一致していい気がするけど、

int y=new {int a=>a+1}.invoke(20); は分かるが、

int y=new {int a=>a+1}(20); これはどうかと思わないか？

プロパティとかクロージャも含めて、言語仕様にリテラルを入れるのは
直接的には省略した記法でしかない。
やっぱり、それを新規に導入するだけのメリットがあるかどうかだろ。

ジェネリクス同様、所詮はCのマクロの置き換えと同じだしｗ

219 ：デフォルトの名無しさん：2008/02/24(日) 22:34:53

そんな使い方しないってw
あほかよ

220 ：デフォルトの名無しさん：2008/02/24(日) 22:44:47

int x = (Integer)new Function("text/javascript", "1+1").invole();

やっぱりこれで良いんですけど。

221 ：デフォルトの名無しさん：2008/02/24(日) 22:45:52

タプルと演算子オーバーロードは、確か、絶対にサポートしないってどこか書いてあった（英語）。
bigdecimalのオペレータ[+,*とか]・オーバーロード・サポートもあんまり期待できない。

byte b; Float o;
{b, o}=init(something);
クラスを定義するほどでもなく、ちょっと利用のつもりでこんな感じだろうけど、

Object[] init(something){return new Object[]{new Byte(2), new Float(2.1)};}
この長い書き方で実質的に展開されるんだろうし、別にリテラルとしてサポートするメリットな意味ない。

クロージャ（GUIイベントを主とした）と違って、あんまり必要としてる人はいないみたい。
配列じゃなくてクラスを返し他方が、他の人が読んでも分かるみたいで、private
で使うんじゃないか？オレなら、publicやprotectedのメソッドでは、こういうAPIがあると作った人を疑っちゃうけどね。

222 ：デフォルトの名無しさん：2008/02/24(日) 22:49:53

演算子オーバーロードのサポートも時間の問題と思われ

223 ：デフォルトの名無しさん：2008/02/24(日) 22:53:26

それと、クラスをメモリ上に一旦読み込んでしまえば、
匿名クラスとかクロージャとかで関数一つでもクラスをいちいち生成される
とか気にしても、性能に全く関係ないよ。

.classでもメモリ上ではCのように速さとか性能はほぼネイティブと同じになるし、
せいぜいメソッドで動的呼び出しか、静的呼び出しかの違いぐらいじゃないか？
それに、C、jvmくらべるより、それよりもIO待ちのほうがはるかに遅くなるｗ

クラスファイルが多くなるだろうけど、jarで固めるだけだし。
javaとかjvmとかは、C++C＃Rubyみたいにプログラマーよりじゃなくて
実はハードよりの言語（と仕様）だったりする。

確かゴスリン(BGGA)もやる気みたいだったし、あとはjdk1.7に間に合うかどうかだろう。
クロージャは1.7の目玉だしな。

224 ：デフォルトの名無しさん：2008/02/24(日) 22:56:34

>>220
それ、何をしたいのかやりたいことは分かるが、そもそもJavaと関係ないだろｗ

225 ：デフォルトの名無しさん：2008/02/24(日) 23:06:29

>>217
匿名クラスがjavaのクロージャなんだけど、
そのクロージャってなんだよｗ

226 ：デフォルトの名無しさん：2008/02/24(日) 23:09:26

java.util.concurrent
GUI使わない案件なら、やっぱりJavaはこれでしょ。
クロージャのほうが先に導入されてるとそれなりに面白かったけど。

227 ：デフォルトの名無しさん：2008/02/24(日) 23:14:33

>>225
匿名クラスがクロージャそのものなのはC#なんでは？

228 ：デフォルトの名無しさん：2008/02/24(日) 23:15:46

>>220
それだけダラダラとタイプ量があるなら匿名クラスと同じ。
ていうか、匿名クラスならまだjavaだけど、それjsだろ。
いつも書いてて絶対に必要になるし、ダラダラ書くの面倒じゃん？ってのが始まりだろう。

229 ：デフォルトの名無しさん：2008/02/24(日) 23:17:51

>>218
俺には「C言語はアセンブリのマクロにすぎないから不要」ってぐらい暴論に聞こえるんだが。
クロージャにしたって、一塊の処理の手続きを「ひとつのオブジェクトでもある」のと「データとは異なるものとしてコンパイラに特別扱いしてもらう」のうち後者以外はすべて異端って扱いはどうなのよ。

230 ：デフォルトの名無しさん：2008/02/24(日) 23:24:33

>>227
C#のクロージャの話をしたいのか。

231 ：デフォルトの名無しさん：2008/02/24(日) 23:26:33

>>229
なかなかの暴論だなｗ
オレには「アセンブリは、所詮はCのベンダー実装に過ぎない」って思ってたけどｗ

232 ：デフォルトの名無しさん：2008/02/24(日) 23:27:24

withLock(lock, {=>
System.out.println("hello");
});
withLock(lock) {
System.out.println("hello");
}
あたりは本当にいろいろと可能性が広がりそうで楽しみ。

Collectionも引数にクロージャ渡すものがかなり拡張されるだろうね。

233 ：デフォルトの名無しさん：2008/02/24(日) 23:28:04

>>230
C#スレでやれよ。

234 ：デフォルトの名無しさん：2008/02/24(日) 23:30:08

>>229
何を実現したいのかと、それをどうやるのかの実装とは、別にして考えてみたらどうだ？
それなら全て異端ってことじゃなく、両立可能だろうな。

235 ：デフォルトの名無しさん：2008/02/24(日) 23:38:09

>>232
Collectionには手を出さないんじゃないか？
ジネリクスと混じってしまってパッと見なんだか分からなくなる。
ジネリクスは目が慣れるまで少し時間がかかったしｗ
コンカレント辺りのブロッキングキュー・クラスとかでやるならまだしも。

236 ：デフォルトの名無しさん：2008/02/24(日) 23:40:35

俺はGenericsは単純すぎて拍子抜けした。
C++使いからみれば単純この上ない。

237 ：デフォルトの名無しさん：2008/02/24(日) 23:54:25

C++が意味不明なんだよ。
それもジェネリクスじゃなくて、C++はテンプレートだろ。
C++のやりたいことは雛形プログラム手法で、Java総称型なんだけど、その様子だと分かってないな。

238 ：デフォルトの名無しさん：2008/02/24(日) 23:59:23

>>220
それ、クロージャじゃなくてevalじゃん。

239 ：デフォルトの名無しさん：2008/02/25(月) 00:02:44

ちなみにおまいらクロージャ候補はどの候補がいいと思うよ？

240 ：デフォルトの名無しさん：2008/02/25(月) 00:10:35

>>238
クロージャーであることが目的になっちゃってるの？

241 ：デフォルトの名無しさん：2008/02/25(月) 00:13:49

>>240
evalだと静的に色々解析できないじゃん

242 ：デフォルトの名無しさん：2008/02/25(月) 00:20:02

内部イテレータが欲しい俺は少数派か？

243 ：デフォルトの名無しさん：2008/02/25(月) 00:23:33

↑具体的にどういうコードになるの？

244 ：デフォルトの名無しさん：2008/02/25(月) 00:24:35

>>240
少なくともevalを多用するのは嫌い。
evalは(たとえ動的言語であっても)最後の武器だと思ってる。

245 ：デフォルトの名無しさん：2008/02/25(月) 00:25:11

2ch は保守派 (というか優位に立ちたい人) しかいないからわざわざ披露しない方が良いよ。

246 ：デフォルトの名無しさん：2008/02/25(月) 00:30:15

html出身の人にはクロージャの意味は分からんのです。

247 ：デフォルトの名無しさん：2008/02/25(月) 00:39:00

>>237
C++の方が機能が多いってだけだろ。
C++だってgenericだぜ。

248 ：デフォルトの名無しさん：2008/02/25(月) 00:39:47

>>245
馬鹿は頭固いから何言ってもダメだしな。
なぜこんなスレに来ているのかわからんが。

249 ：デフォルトの名無しさん：2008/02/25(月) 01:02:42

JavaのGenericsを批判している人も批判していない人も、型引数への制約やワイルドカード型引数といった
JavaのGenericsの機能を本当に使いこなせている？

Google作成のGuiceあたりはGenericsを多用しているので、勉強になる。
これらのソースをすらすら理解でき改造できるようになってから、批判しよう。

250 ：デフォルトの名無しさん：2008/02/25(月) 01:08:50

あの程度理解できない人間はこのスレに来るべきじゃないよ

251 ：デフォルトの名無しさん：2008/02/25(月) 01:21:01

clone() じゃねーけど、減らす仕様もロードマップに示して欲しいなー。
@Deprecated じゃないけど「旧仕様互換ソースはコンパイルできるが新仕様準拠ソースは
コンパイルエラー/ただしランタイムは解決可能」みたいなアノテーションでも作って。

252 ：デフォルトの名無しさん：2008/02/25(月) 01:37:26

それはコンパイルオプションで解決すりゃいいことでは

253 ：デフォルトの名無しさん：2008/02/25(月) 04:54:50

使う方のソースはそれで良いけど宣言する方のソースはアノテーション必要でしょ。

254 ：デフォルトの名無しさん：2008/02/25(月) 05:55:52

やっぱりC＋＋出身者は、個人的な問題を指摘する事が多いね。

255 ：デフォルトの名無しさん：2008/02/25(月) 09:14:43

cloneって何か変わるの？？

256 ：デフォルトの名無しさん：2008/02/25(月) 14:10:28

>>245
だれだおまえ？

257 ：デフォルトの名無しさん：2008/02/25(月) 21:27:34

私の名はクリストファー・エリクソン。

258 ：デフォルトの名無しさん：2008/02/25(月) 21:28:14

よう！くりちゃん！！久しぶり！！

259 ：デフォルトの名無しさん：2008/02/25(月) 22:15:22

>>250
ずいぶんと自信過剰ですな。
ところでJVMの実装とかあなたはできるんですか？

260 ：デフォルトの名無しさん：2008/02/25(月) 23:09:49

>>222
おまえはだれだ？

261 ：デフォルトの名無しさん：2008/02/26(火) 00:19:24

ボクハ、オンガクカ、デンタクカタテニ

262 ：デフォルトの名無しさん：2008/02/26(火) 00:28:42

もうjava2Kでいいじゃん

263 ：デフォルトの名無しさん：2008/02/26(火) 00:46:08

>>259
GenericsとJVM実装って全然別やん…

264 ：デフォルトの名無しさん：2008/02/26(火) 00:55:26

なんか、味噌でも糞でもとにかく延々と追加して行かなければいけないような雰囲気だねー。
マッチポンプで仕事作ってるようも見える。

265 ：デフォルトの名無しさん：2008/02/26(火) 02:46:25

C＃がね。

266 ：デフォルトの名無しさん：2008/02/26(火) 02:51:58

clone()ってなくなるの？

267 ：デフォルトの名無しさん：2008/02/26(火) 07:47:39

珍妙なもんを削る方向にも進めということでしょ。

268 ：デフォルトの名無しさん：2008/02/26(火) 09:27:53

チンチンを削ちゃうの？

269 ：デフォルトの名無しさん：2008/02/26(火) 09:27:55

>>266
今更削除できないと思うが。

270 ：デフォルトの名無しさん：2008/02/26(火) 09:47:04

clone削除されたら困るんだが

271 ：デフォルトの名無しさん：2008/02/26(火) 10:05:15

されないw

272 ：デフォルトの名無しさん：2008/02/26(火) 11:57:23

やっぱり小さいチンチンは削除です

273 ：デフォルトの名無しさん：2008/02/26(火) 14:30:54

>>245
全く何を言いたいのか意味不明なんだが、もっと分かりやすく書き直してくれないか？

274 ：デフォルトの名無しさん：2008/02/26(火) 20:17:29

>>268
尖らすの？

275 ：デフォルトの名無しさん：2008/02/26(火) 23:06:10

ちぎり取るんだろ

276 ：デフォルトの名無しさん：2008/02/27(水) 00:32:49

結局プロパティってなくなったの？
boundのダウンキャスト地獄な仕様みた瞬間うんざりしたからいらんけど。

277 ：デフォルトの名無しさん：2008/02/27(水) 00:44:36

getter/setterでいいよな別に。
アクセッサの表記にget/setがなくなる程度のメリットしかない気がする。

278 ：デフォルトの名無しさん：2008/02/27(水) 00:53:16

ワンモアセッ！

279 ：デフォルトの名無しさん：2008/02/27(水) 01:34:49

>>277
例えばどうやるの？

280 ：デフォルトの名無しさん：2008/02/27(水) 01:40:24

Property Spec (draft 3)の次ってあるの？
ぐぐってもv4とかなさげなんだけど

281 ：デフォルトの名無しさん：2008/02/27(水) 01:50:35

Seasarのpublicフィールドみたいなことを
勝手にやられるより、あったほうが良いんじゃないか？

282 ：デフォルトの名無しさん：2008/02/27(水) 01:58:51

どうなんの?
何かアノテーションとコンパイラのサポートで十分な気がするけどこれも言語仕様変える気?

283 ：デフォルトの名無しさん：2008/02/27(水) 03:34:44

プロパティなんてメソッド経由のアクセスで十分だろ。なに必死になってんのｗ

284 ：デフォルトの名無しさん：2008/02/27(水) 04:06:28

clone()がどうとうかこうとかも、意味不明なことをいう変質者が多いな。

285 ：デフォルトの名無しさん：2008/02/27(水) 05:19:15

ああ。なんだか何いってんのかわかんない奴が最近多いよ。
やっぱ春だな

286 ：デフォルトの名無しさん：2008/02/27(水) 10:43:09

プロパティはもう入らないんじゃないかな。

クロージャは入るだろうけど。
>>232のような制御構造に近い記述のメリットが大きいから。
並列とか制御に関するクラスの記述に便利だしね。

287 ：デフォルトの名無しさん：2008/02/27(水) 10:46:12

やっぱ、break, returnだろ。
てか、偶然に速レスになってるし。

288 ：デフォルトの名無しさん：2008/02/27(水) 14:56:53

プロパティとかクロージャとかどうでもいいから
XMLリテラルとソースファイルのエンコード指定と
RAW文字列？みたいな今不便なところを改善する機能をはやく取り入れてほしい

289 ：デフォルトの名無しさん：2008/02/27(水) 16:20:49

XMLリテラルはXjが最有力と言われた時期もあったけど、
もう入らないと思う。最近続報が全くないので。当時の賛否を考えると、
here documentであることよりもXMLであることがネックになってると思われ

290 ：デフォルトの名無しさん：2008/02/27(水) 16:54:45

ヒアドキュメントより文字列リテラルに変数変数埋め込めるようにして欲しい。
+結合だと冗長になる。

291 ：デフォルトの名無しさん：2008/02/27(水) 21:17:53

そういう機能作ると半分の人間が動的に作成した文字列に値が入らないか心配しはじめるだろう。

292 ：デフォルトの名無しさん：2008/02/27(水) 21:21:11

変数変数って何よ？

293 ：デフォルトの名無しさん：2008/02/28(木) 00:16:52

XMLリテラルとか変数変数とか向こうで要望出したらどうだ？（当然英語だけどｗ）

294 ：デフォルトの名無しさん：2008/02/28(木) 06:07:06

ようはEL式風のヒアドキュメントがあればHappyってこったな

295 ：デフォルトの名無しさん：2008/02/28(木) 22:47:11

null代入を禁止する型が欲しい。
契約プログラミングまでいかなくていいので、
派生型としてnull代入を禁止する型がほしい。

296 ：デフォルトの名無しさん：2008/02/28(木) 22:55:28

>>295
FindBugs の @NonNull で我慢

297 ：デフォルトの名無しさん：2008/02/28(木) 22:59:00

>>296
できれば代入操作時にnullが指定されたら動的に例外投げてくれるような仕組みがあるとうれしいんだけどね。
FindBugsのそれはしらなかったよ。使ってみる。

298 ：デフォルトの名無しさん：2008/02/29(金) 04:57:36

このnullについては、ライブラリや言語（仕様）やjvmで解決できる問題じゃないと思うんだが、単んに愚痴をこぼしてるだけ？

299 ：デフォルトの名無しさん：2008/02/29(金) 05:08:38

JVM まで持ち出すなら何でもできるじゃん。

300 ：デフォルトの名無しさん：2008/02/29(金) 05:21:03

正直イラン

301 ：デフォルトの名無しさん：2008/02/29(金) 07:48:05

そしてJavaは「C++Jあヴぁ」となりました。

302 ：デフォルトの名無しさん：2008/02/29(金) 22:48:25

>>298
既存のライブラリを呼ぶときキャストの嵐になるのを覚悟すれば、
null代入可能なものと不可能なものを型システムで区別すること自体は簡単。
Cでいうと、普通のポインタはNULLポインタ型と非NULLポインタ型のunionだと思えばいい。

303 ：デフォルトの名無しさん：2008/02/29(金) 22:58:23

バグ検知のための利便性向上目的でしょ。アスペクソ指向 & アサーション方面からの
アプローチでする話じゃないのかな。String s not null と思いつきで書いてみると、いずれ
テーブルのカラム宣言のようなカオスになりそうだが。

304 ：デフォルトの名無しさん：2008/03/01(土) 00:45:54

俺の欲しいのとしてはこんな感じ：
String! s; s = null; // 文法エラー
String t = null; s = t; // 実行時エラー

public void hoge(final String! s){
s.~~(); // 絶対にNullPointerExceptionがおこらない
}

class Hoge<T!>{ }
List<Object!> o = anotherList; // 要素がnullでもとおっちゃうなあ…

305 ：デフォルトの名無しさん：2008/03/01(土) 00:54:30

こんな保守的なところでアイディアを披露しても時間の無駄だよ。
JCP のケツ追いしかできない連中が集まってるところだから。

306 ：デフォルトの名無しさん：2008/03/01(土) 01:24:46

アノテーションで十分だろ

307 ：デフォルトの名無しさん：2008/03/01(土) 01:45:19

>>305
JCPになりようもない愚論を大声で喚いている奴より、
JCP追うだけの奴の方がずっとましで有益です。

308 ：デフォルトの名無しさん：2008/03/01(土) 01:48:34

自覚はあるようですね。

309 ：デフォルトの名無しさん：2008/03/01(土) 02:51:28

英語読むのも書くのも面倒くさいんじゃ

310 ：デフォルトの名無しさん：2008/03/01(土) 04:37:53

nullについてはtry catchでナルポ補足いいんだろ。
また俺様仕様のC＋＋の癖が出でるねｗ

311 ：デフォルトの名無しさん：2008/03/01(土) 04:52:33

「こんな保守的」ってのは
どうしてこういう発想になるんだろう？

312 ：デフォルトの名無しさん：2008/03/01(土) 09:54:18

>>304
String! s; //<この時点でエラーじゃねーのか？

あと、nullを代入する時点で実行時エラーにするのは、パフォーマンス的にムリ。
setX(X x) { if (x == null) throw NullPointerException("X is not nullable"); this.x = x; }
とかしとけ。

313 ：デフォルトの名無しさん：2008/03/01(土) 10:30:55

operator overloadがあれば可能だけど、
nullを代入してはいけないのに、してしまうなんてださいコードだね。

314 ：デフォルトの名無しさん：2008/03/01(土) 10:32:55

大抵こういう流れになります。

315 ：デフォルトの名無しさん：2008/03/01(土) 11:00:36

>>313
Javaみたいな静的型言語だと、operator overload を使って null 代入チェックしようとすると
クラス単位で null代入可能か不可能かを決めなくちゃいけなくなって逆に不便なような気もするが。

316 ：デフォルトの名無しさん：2008/03/01(土) 11:31:55

でもやっぱりnonnull欲しいよなあ。言語仕様的に。何だっけ？ぷりえんぷてぃぶとか言うんだっけ？
Curlとか触ってると、ホントこれはいいアイデアだと思える。

317 ：デフォルトの名無しさん：2008/03/01(土) 11:34:22

null代入で実行時エラー？
そんな糞仕様は勘弁してくれ

318 ：デフォルトの名無しさん：2008/03/01(土) 11:41:45

>>317
なんでも静的にやろうとするとリフレクション経由で弄った時に簡単に破綻するような。

319 ：デフォルトの名無しさん：2008/03/01(土) 11:51:51

>>316
つ JSR-305

320 ：デフォルトの名無しさん：2008/03/01(土) 12:06:26

要するに @NonNull > JSR-305

321 ：デフォルトの名無しさん：2008/03/01(土) 12:07:40

@CheckForNullってのもある

322 ：デフォルトの名無しさん：2008/03/01(土) 12:11:04

@NetHome

323 ：デフォルトの名無しさん：2008/03/01(土) 12:33:39

そういうのはそもそも設計上の問題じゃないのか？

324 ：デフォルトの名無しさん：2008/03/01(土) 12:41:26

debug用annotationだし。> 305
言語にいれろって言っている奴は馬鹿だし。>>304

325 ：デフォルトの名無しさん：2008/03/01(土) 12:50:12

NullPointerExceptionとassertを使い分ければいいだけだからいらんな

326 ：デフォルトの名無しさん：2008/03/01(土) 13:02:14

AspectJかJavassist使えばいいんじゃね？

327 ：デフォルトの名無しさん：2008/03/01(土) 14:03:41

多分、奴の頭の中では「C++じゃヴぁ」を考えてるんだろうｗ

328 ：デフォルトの名無しさん：2008/03/01(土) 14:10:19

>>307
よう、この流れのどこが有益なんだ？

329 ：デフォルトの名無しさん：2008/03/01(土) 14:21:08

粘着ｷﾀｰw

330 ：デフォルトの名無しさん：2008/03/01(土) 14:30:45

自意識過剰すぎ

331 ：デフォルトの名無しさん：2008/03/01(土) 14:36:25

思いつきをここに書き込むことでJavaをよりよくしてくださって本当にありがとうございました

332 ：デフォルトの名無しさん：2008/03/01(土) 20:42:27

こういう連中がいることでオタクが嫌われるんだろうなあ

333 ：デフォルトの名無しさん：2008/03/02(日) 03:30:15

いい加減、みんなの夢を詰め込んだJava3を作ってくれないかな？

そしてぶちぎれた誰かが、FreeJavaとかNetJavaとか作ればいいと思うお。(*´∀`)

334 ：デフォルトの名無しさん：2008/03/02(日) 03:36:30

SunがJavaと呼称するのは禁止させるだろ。

335 ：デフォルトの名無しさん：2008/03/02(日) 03:37:45

そんなことしなくても既に JCP が輪姦中じゃん。

336 ：デフォルトの名無しさん：2008/03/02(日) 06:43:25

>>333
Java OSとかOpenJavaがないのはネタ？

337 ：デフォルトの名無しさん：2008/03/02(日) 06:44:57

というか、Javaというのは言語とライブラリ群であって、
実体はjvm用のバイトコードを生成するコンパイラなんだけど。

だから好きなだけJRubyとかJC++とかJC99とかのコンパイラ作れよｗ
（多分君らのようなMSーC＋＋厨じゃ無理だろうけどｗｗ）

338 ：デフォルトの名無しさん：2008/03/02(日) 10:37:54

実体とかアホじゃないの？

339 ：デフォルトの名無しさん：2008/03/02(日) 10:42:33

アホだな。
JVMやバイトコードの仕様拡張を含むJCPの議論を知らない知ったか厨だろ。

340 ：デフォルトの名無しさん：2008/03/02(日) 11:17:14

>バイトコードの仕様拡張を含む...
ずっと昔から議論されてるみたいだけど、どの程度すすんでるの？

341 ：デフォルトの名無しさん：2008/03/02(日) 11:23:42

>>338-339
また湧いてきたｗ
もう春かｗｗ

342 ：デフォルトの名無しさん：2008/03/02(日) 11:43:23

wを多用するとバカっぽいのは分かった。

343 ：デフォルトの名無しさん：2008/03/02(日) 11:52:59

今頃そんな事分かったのか…

344 ：デフォルトの名無しさん：2008/03/02(日) 12:10:31

アノテーションのためにクラス・ファイルが拡張されたのを勘違いしてるんだろ

345 ：デフォルトの名無しさん：2008/03/02(日) 12:15:59

ハァ？おまえが勘違いしてね？

346 ：デフォルトの名無しさん：2008/03/02(日) 14:33:29

javaはプラットフォーム一式なんだが

347 ：デフォルトの名無しさん：2008/03/02(日) 15:52:59

JavaScript, JRubyとかはどうなるんだ？

348 ：デフォルトの名無しさん：2008/03/02(日) 15:53:55

厨房がこのスレに潜伏中の模様！注意せよ！！

349 ：デフォルトの名無しさん：2008/03/02(日) 16:26:35

社員じゃなくてバイトがコード書いてるの？

350 ：デフォルトの名無しさん：2008/03/02(日) 16:49:33

マイクロソフトの下請けとかそうんかんじらしいよｗ

351 ：デフォルトの名無しさん：2008/03/02(日) 18:53:33

＞アノテーションのためにクラス・ファイルが拡張されたのを勘違いしてるんだろ
はぁ？アホじゃねぇの？
アノテーションはバイトコード内の属性用のブロックに格納されますが？

352 ：デフォルトの名無しさん：2008/03/02(日) 19:12:06

何で「あなた」ごときがそれを知ってるんですか？

353 ：デフォルトの名無しさん：2008/03/02(日) 19:22:11

厳密にいうとバイトコード内ではなくてクラスファイル内というべきだが
クラスファイルの仕様は公開されてるんだから調べればわかる
http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf

354 ：デフォルトの名無しさん：2008/03/02(日) 20:09:57

アホテーションはどこに格納されてますか？

355 ：デフォルトの名無しさん：2008/03/02(日) 21:08:32

お前の頭の中にあるんじゃねーのか？

356 ：デフォルトの名無しさん：2008/03/02(日) 21:59:15

>>353
何で「あなた」ごときがそれを知ってるんですか？

357 ：デフォルトの名無しさん：2008/03/02(日) 22:00:49

>>351はアホだね。

358 ：デフォルトの名無しさん：2008/03/02(日) 22:41:20

おいおい、ほかの言語にももっと目を向けろよ。
Not Nullにする構文がどんだけ有益なことかわからんのか。

359 ：デフォルトの名無しさん：2008/03/02(日) 22:43:26

>>358
せまい世界の問題に何を必死になってんだか

360 ：デフォルトの名無しさん：2008/03/02(日) 23:13:24

じゃあJavaは今のままで問題ないとでも？

361 ：デフォルトの名無しさん：2008/03/02(日) 23:14:41

>>325

362 ：デフォルトの名無しさん：2008/03/02(日) 23:50:07

ぬるぽ

363 ：デフォルトの名無しさん：2008/03/03(月) 04:32:20

そんな考えだから衰退していくんだ

364 ：デフォルトの名無しさん：2008/03/03(月) 04:42:11

だからこんなところで発案するだけ無駄だと言ったろう。
お上から落ちてきた仕様書の解釈論程度の能力しかない下請け連中が集まってるだけなんだから。

365 ：デフォルトの名無しさん：2008/03/03(月) 06:41:33

>>363
というかおまえはJavaa使うな。
おまえはJavaaで何が作れて、Javaaに何期待してるんだ？
吠えてるだけで何も作れない奴はこのあたりで黙っちゃうだがなｗｗｗん？

366 ：デフォルトの名無しさん：2008/03/03(月) 07:29:46

それが良いアイデアだと妄信してる時点で終わってるでしょ
見た目をちょっと変えるだけで何の革新でもないし、
コーディングスタイルの歪な文化をひとつ増やすだけでも迷惑。

367 ：デフォルトの名無しさん：2008/03/03(月) 07:37:40

それはアノテーションのことかクロージャーのことか、どれの事言ってんだ?

368 ：デフォルトの名無しさん：2008/03/03(月) 08:14:48

Java学習暦2ヶ月の厨房が吠えてるんでしょうｗ春だしｗ

369 ：デフォルトの名無しさん：2008/03/03(月) 09:01:12

------------- ここまでテンプレ -------------

370 ：デフォルトの名無しさん：2008/03/03(月) 09:28:05

----------- ここからプロローグ -----------

371 ：デフォルトの名無しさん：2008/03/03(月) 21:16:39

>>366
そうではない。
進化をとめた言語は、死んだも同然。
C++を見てみろ。

372 ：デフォルトの名無しさん：2008/03/03(月) 21:18:17

C++は革新だらけの言語だが…
むしろ革新多すぎw

373 ：デフォルトの名無しさん：2008/03/03(月) 21:24:41

C++0x はどうせ VC++ で実装されないと踏んでるのですね。

ありえそうで怖い。

374 ：デフォルトの名無しさん：2008/03/03(月) 21:29:16

C99はいつになったら

375 ：デフォルトの名無しさん：2008/03/03(月) 21:34:49

C++だって糞みたいな提案は拒否されてる。>>366に同意。

376 ：デフォルトの名無しさん：2008/03/03(月) 21:41:01

お前らごときが何エラそうに評価してんだｗ

377 ：デフォルトの名無しさん：2008/03/03(月) 21:43:52

お前ごときが口出しするな

378 ：デフォルトの名無しさん：2008/03/03(月) 21:48:45

ﾌﾟｯ
2ch で吠えるなよ～ｷｬﾝｷｬﾝｗ

379 ：デフォルトの名無しさん：2008/03/03(月) 22:05:32

じゃこのスレいらないね

380 ：デフォルトの名無しさん：2008/03/03(月) 22:06:21

>>374
GCC拡張で良いんじゃね？

381 ：デフォルトの名無しさん：2008/03/03(月) 22:08:53

VCで実装うんちゃらとかいってる時点で厨房だろｗｗｗｗここJava擦れだしｗｗ
花見気分で様子見してろよｗｗｗｗ分かるからｗｗｗｗｗ

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

382 ：デフォルトの名無しさん：2008/03/03(月) 22:15:39

厨房注意報出てるんだから、スルーしろよ
といってもこのスレの住人レベルじゃ無理だろうけどｗ

383 ：デフォルトの名無しさん：2008/03/03(月) 23:17:29

NonNullとかでガチガチにしても結局たいして意味ないんだよな

384 ：デフォルトの名無しさん：2008/03/04(火) 00:44:12

ヌルポが回避できたって、テキトーな初期値が入れられるだけなんだったら意味無いからな。
それなら、ヌルポ出して、その変数に入れるべき値を考察させればいい。

385 ：デフォルトの名無しさん：2008/03/04(火) 02:36:17

ラムダがint hoge => hoge という形になると
Javaは生涯C#に追いつけないことが確定するからな

386 ：デフォルトの名無しさん：2008/03/04(火) 07:24:02

>>380
いつになったらVLAを関数に渡せるようになるの

387 ：デフォルトの名無しさん：2008/03/04(火) 08:10:47

未だにJavaとMS（VC++VBC#)を比べてるガキがいる件について語ろうではないか

388 ：デフォルトの名無しさん：2008/03/04(火) 11:23:39

Javaは一生懸命C#に追いつこうと機能追加しとるじゃない

389 ：デフォルトの名無しさん：2008/03/04(火) 11:28:39

ちなみにプロパティも属性もボクシングもC#は1.0からもってる
クロージャは2.0で持ってる
今は3.0ね

390 ：デフォルトの名無しさん：2008/03/04(火) 11:44:16

ニートはこんなすれに粘着してないで早く面接行けよｗ

391 ：デフォルトの名無しさん：2008/03/04(火) 18:40:02

C#のプロジェクトって早くもデスマってるのが多いよ

392 ：デフォルトの名無しさん：2008/03/04(火) 18:45:28

C#は始めから迷走してるからな。何がやりたいのか分からん

393 ：デフォルトの名無しさん：2008/03/04(火) 18:53:44

>>391
このスレ関係ないし、まったく興味ないから知らないな。
例えばどれ？

394 ：デフォルトの名無しさん：2008/03/04(火) 19:04:03

>>393
関係ないといいつつ話を継続させようとするな

395 ：デフォルトの名無しさん：2008/03/04(火) 19:14:50

じゃ、はよ消えてくんろ

396 ：デフォルトの名無しさん：2008/03/04(火) 19:34:36

>>393
馬鹿かおまいはｗ

397 ：デフォルトの名無しさん：2008/03/04(火) 19:45:52

今IT業界ではJavaこそが諸悪の根源とされてるのを知らんのか

398 ：デフォルトの名無しさん：2008/03/04(火) 19:53:58

いやおまいらみたいな無能労働層だろｊｋ

399 ：デフォルトの名無しさん：2008/03/04(火) 19:56:38

>>392
C#は1.0の時から3.0の機能は全部予定してたから今のところ何の破綻もない
一直線だ
むしろ迷走してるのはJavaだな
言語仕様を民主的に決める必要なんてかけらも無いのに

400 ：デフォルトの名無しさん：2008/03/04(火) 20:02:23

Javaは方向性も、ビジョンもないからな。
ほんと、これからどうして行きたいのかがわからん

401 ：デフォルトの名無しさん：2008/03/04(火) 21:58:06

このC#厨房は何をしにきたたたたたたたたんだ？

402 ：デフォルトの名無しさん：2008/03/04(火) 22:01:41

自慢しに来た

403 ：デフォルトの名無しさん：2008/03/04(火) 22:06:36

まあ実際、近視眼的な部分はあるよ。
JCPはとどのつまり企業連合な組織だし。
EE6でSpringやS2が壊滅したらちょっと面白い。

404 ：デフォルトの名無しさん：2008/03/04(火) 22:48:56

まぁ、いまのところEE勢が壊滅した事しかないのが笑えるよな。

405 ：デフォルトの名無しさん：2008/03/04(火) 23:05:31

なんかunrestricted closureも実装してきているなあ。> BGGA実装

jsr166z.forkjoinもかなりいろいろ増えてるし。
Control invocation syntaxが楽しくてたまらん(ﾊｧﾊｧ

406 ：デフォルトの名無しさん：2008/03/04(火) 23:12:13

クロージャは次期採用はほぼ固まったみたいでもう追いかけてないんだけど、どお、便利？

407 ：デフォルトの名無しさん：2008/03/05(水) 00:27:08

無名内部クラスがあるのにクロージャも作るのか

408 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/05(水) 10:09:05

ruby使ってる奴らは未だにクロージャとイテレーターの区別ついてないだろうけど。
javaやるとクロージャはどういうのかがやっと理解できるのかもな。

410 ：デフォルトの名無しさん：2008/03/05(水) 10:11:44

連中にクロージャなんて意識ないだろ？

411 ：デフォルトの名無しさん：2008/03/05(水) 10:21:06

レスはえーなｗ
javaの連中もイベント処理でクロージャ（匿名クラス）使ってるって意識はないだろう
イテレータよりは匿名クラス・デリゲートｗのほうがクロージャっぽいけど、まあどっちも同じだ

で、使ってみた感想は将来有望とか利用できるアイディアはいろいろ浮かんでくるか？

412 ：デフォルトの名無しさん：2008/03/05(水) 17:31:20

もうJavaはすててScalaでいいんじゃね？

413 ：デフォルトの名無しさん：2008/03/05(水) 18:35:20

俺はrhino派だな。手続き型+OOP+関数型のマルチパラダイムは便利だ。

414 ：デフォルトの名無しさん：2008/03/05(水) 18:36:24

クロージャと匿名クラスは違う
ローカル変数をクロージャが実行される時まで取っておくのが
クロージャの性質だ

415 ：デフォルトの名無しさん：2008/03/05(水) 18:37:18

final 宣言すりゃとっておけるじゃん。

416 ：デフォルトの名無しさん：2008/03/05(水) 18:53:02

たとえばオープンした後自動的にクローズするような処理にもクロージャは便利だ

new File(path).Read(Input in){
...
}

ブロックを抜けたあと勝手にCloseしてくれるようにできる

417 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/05(水) 23:41:19

>>405
> Control invocation syntaxが楽しくてたまらん(ﾊｧﾊｧ

構造化プログラミングでいうところの構造的な制御構造は何でも作れますね。
ifとかwhileとか。

継続とtail jumpがないから非構造的な制御構造は無理だけど。
ただサンプル実装では、>>405の通り、
returnでクロージャの外の関数を出られる実装が出てきそうだけど。

420 ：デフォルトの名無しさん：2008/03/05(水) 23:50:11

参照渡しはまだかね。

421 ：デフォルトの名無しさん：2008/03/05(水) 23:53:00

finalな変数だけ運べれば十分な気がするな
普通の変数を突っ込まなきゃならないケースが思いつかないし
ややこしくて危険でもある気がする

422 ：デフォルトの名無しさん：2008/03/05(水) 23:54:18

finalじゃなくても適当にfinalを仮定してくれればいいやー

423 ：デフォルトの名無しさん：2008/03/05(水) 23:57:14

ローカル変数がスコープ外の影響受けるなんてのは漏洩の副作用と言った方が良い。
リターンバッファのようにあからさまに意図したものならともかく。

424 ：デフォルトの名無しさん：2008/03/05(水) 23:58:33

アノテーションにまで手を伸ばすのは止めて欲しいな。
こんなんじゃXML hellがAnnotation hellに置き換わるだけだ。

425 ：デフォルトの名無しさん：2008/03/06(木) 00:13:42

全く。
アノテーションは、プログラムに付ける付箋紙のような役割から
ロジックと複雑に絡み合ったカオスの元になりつつあるな。
プログラム的な定義は、言語として定義してくれ。

@Shared　アノテーションは、アノテーションの誤用としか思えない。

426 ：デフォルトの名無しさん：2008/03/06(木) 00:24:43

勝手な言語拡張をするんじゃなくて、
処理系独自の意味を与えられる(Cの#pragmaのように)
アノテーションを使っているだけだと思います。
もし必要だということになれば、修飾子になるのでしょう。

Doug Lee大先生が今この辺りのことをどうしているかは追えてないです。

ただ並列に動いているクロージャ同士が、
「環境」を共有しているって状況はとても自然で、応用によっては有益なので、
full closureはいつか入るだろうし、また入るべきだと思います。

427 ：デフォルトの名無しさん：2008/03/06(木) 00:26:23

>>425
サンプル実装と仕様提案を混同して議論しないようにしましょう。
>>418に書いたのはサンプル実装のことで、
@Sharedを使うなんて提案は全くありません。

428 ：デフォルトの名無しさん：2008/03/06(木) 00:27:13

Swing App frameworkのActionアノテーションも間違ってる気がする

429 ：デフォルトの名無しさん：2008/03/06(木) 00:31:41

環境といえば、JSR-323が否決されてたような。

430 ：デフォルトの名無しさん：2008/03/06(木) 00:35:45

試行錯誤中だし、戯言に付き合うのも程ほどにｗ

431 ：デフォルトの名無しさん：2008/03/06(木) 00:39:37

JSR-323って、サマリを見たら昔流行った
MobileAgent系の話のように見えるけど、なんでOS仮想化技術が出てくるんだろう・・・？

Voteのコメントが、何か学生の研究に対するコメントのようで笑えてしまった。

432 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/06(木) 00:53:29

歴史的クロージャ

434 ：デフォルトの名無しさん：2008/03/06(木) 00:58:50

>>431
あそこで言っている仮想化は、
OSに対して行う仮想化じゃなくて、
OSがリソースに対して行う仮想化。

例えば、JavaにIPアドレスをmobile可能にする細工を入れるんじゃなくて、
Mobile IP使えば解決する、まあそんな話。

幾らなんでも早急だったと思うし。研究としては悪くないけど。

435 ：デフォルトの名無しさん：2008/03/06(木) 09:44:35

昔はやっと言うよりも、当時の技術（特にハード）で実用的じゃなくて破棄されたけど、
今なら出来そうだというところが大きいんじゃないか。
次は見た目関数型らしきのも入れて、そんなJavaはsmalltalkとかを中心とした昔の技術の集大成でしかないしｗ

436 ：デフォルトの名無しさん：2008/03/06(木) 09:47:15

昔に流行った

437 ：デフォルトの名無しさん：2008/03/06(木) 10:02:45

>>432
ここは最新追っかけだし、せっかくならJava話をしてC＃の話もついでに披露してくれないか
たとえば、おまえの頭にはMacやLinuxにはすごいハッカーがたくさんいるとか考えた事もないだろ？

438 ：デフォルトの名無しさん：2008/03/06(木) 10:07:22

>>437
何いってんのかわかんねえけど俺はクロージャにはfinalなローカル変数が入れられれば
十分だと思っていて、C#ではfinal以外が入れられることでどういう不都合が起こるかを述べている

439 ：デフォルトの名無しさん：2008/03/06(木) 10:14:16

>>438
>>432って不都合か？せいぜい「評価されるタイミングが俺の好みじゃない」っつーだけのような。

初心者が使いやすい、あんな記述やこんな記述でトラブルの元になってるとか、
そこらへんまで言わないとfinal以外が入れられると不都合、って話にはならんような。

440 ：デフォルトの名無しさん：2008/03/06(木) 10:14:19

>>437
お前痛いよ

441 ：デフォルトの名無しさん：2008/03/06(木) 11:37:23

>>439
C#の話はいいです。

442 ：デフォルトの名無しさん：2008/03/06(木) 12:05:48

>>441
C#の話じゃないって。
unrestricted closure には、取り囲むスコープの変数なら final も @Shared もなしで取り込める。

443 ：デフォルトの名無しさん：2008/03/06(木) 12:38:30

unrestrictedはJava7には入りそうにないね。

444 ：デフォルトの名無しさん：2008/03/06(木) 13:17:41

結局C＃とかC＋＋の部外者がいると荒れるわけですか
少し花見でもしてたつもりですけど、それなら徹底的に排除するまでですけど？

445 ：デフォルトの名無しさん：2008/03/06(木) 13:25:25

>>437
linux, macの奴らはC#など触ったこともないだろ。
奴らの話を聞くだけで耳が腐るｗ
所詮C＃はドカタ候補専用だしな

446 ：デフォルトの名無しさん：2008/03/06(木) 13:34:48

だから言ってるだろ？C＃厨房の相手なんかするなよｗ

447 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/06(木) 13:38:43

そうだな。C＃なんて脳みそはVBの奴らとドッコイなのに、こいつらとJavaを同じにされちゃたまらないな。
いつの時代もMSの奴らはキモイってことだな

449 ：デフォルトの名無しさん：2008/03/06(木) 13:56:44

>>447
javac.infoの実装だと、
unrestrictedは==>で区別することになってますね。
=>はjava.lang.RestrictedFunctionなクロージャ。

450 ：デフォルトの名無しさん：2008/03/06(木) 14:03:34

>>449
それは知ってる。
けど unrestricted 入れないつもりなら unrestricted と restricted の区別なんか必要ないんだから
java.lang.RestrictedFunction 自体要らないでしょ。

451 ：449：2008/03/06(木) 14:04:30

でしょって俺に言われても困るけどねw

452 ：デフォルトの名無しさん：2008/03/06(木) 14:20:49

>>440
おれにはJava最新追っかけスレでC#のことをウダウダ言う奴の方がどう見ても痛い
たぶんおまえの方が痛いｗ

453 ：デフォルトの名無しさん：2008/03/06(木) 14:22:52

C#しか脳がないニートは、はよ面接行けｗｗ

454 ：デフォルトの名無しさん：2008/03/06(木) 14:37:56

MS厨ってどこにでも沸くKYだな

455 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/06(木) 14:57:51

クロージャ厨房も同じくウザイ

457 ：デフォルトの名無しさん：2008/03/06(木) 15:03:45

あと変更入りそうなのは non-local return と local return あたりかなぁ。
{ => method(); } と { => method() } と、ぱっと見て区別つかん。

458 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/06(木) 15:41:22

>>418
今日落としたプロトタイプ実装だと、
@Sharedつけなくても警告がでるだけでコンパイルエラーにならんような

これ、ホームページには updated 2008-02-22 って書いてあるけど、
解凍すると closures-2008-03-05ってディレクトリができる……
コッソリと何か変わってたりするんだろうか？

460 ：デフォルトの名無しさん：2008/03/06(木) 16:36:45

ああ、それなら最近変ったんじゃないかな。> @Sharedいらず
2008-02-26ってのもあるし。

461 ：デフォルトの名無しさん：2008/03/06(木) 19:22:17

2008-02-12 が残ってたから @Shared なしを試してみたけど
警告は出るけどコンパイルエラーにはならなかった。

462 ：デフォルトの名無しさん：2008/03/06(木) 19:37:46

単にコンパイルエラーにするのが面倒なだけじゃね

463 ：デフォルトの名無しさん：2008/03/06(木) 20:12:41

クロージャの話を他の言語で例示しただけでフルボッコされるなんて、
このスレじゃまともな技術的議論はできそうにないな

464 ：デフォルトの名無しさん：2008/03/06(木) 20:27:43

そりゃ保守の集まりでしかないから論議なんかはじめからする気ないんじゃ。
JCP = バチカン、JSR = 教典、それ以外の論議 = 異端 = 叩き、な
ご熱心な殉教者しか居ないのは昔からの事。あ、こりゃ保守というか権威主義か。

465 ：デフォルトの名無しさん：2008/03/06(木) 21:12:55

おまえ毎日同じこといってるな

466 ：デフォルトの名無しさん：2008/03/06(木) 21:14:48

そりゃこんだけ毎度同じパターンばかり見せれるとな。

467 ：デフォルトの名無しさん：2008/03/06(木) 21:26:17

で、Javaのクロージャの場合>>432は
10,10,10...？0,1,2,3,4...？

468 ：デフォルトの名無しさん：2008/03/06(木) 23:18:14

保守の集まりというのは以前も書いてあったけど、一体どういうことだよ。
バチカンとか経典とか、お前頭は相当おかしくなっちまってるようだなｗ

469 ：デフォルトの名無しさん：2008/03/06(木) 23:20:00

C++（C#?)のやりすぎだろ。ストールマンの友達かなんかだろ。たぶん。

470 ：デフォルトの名無しさん：2008/03/06(木) 23:32:55

>>463
技術的な議論とかしたいなら、せめてJavaスレにふさわしくJavaでやれよ。
C＃スレでPHPとかVBとかで議論wとか通用しないのと同じだろ。
これに気がつかないおまえのバカさ加減にあきれるw

471 ：デフォルトの名無しさん：2008/03/06(木) 23:33:08

>>432
それスタックの状態を保存するという考えに基づけば正常な動作じゃないか？

472 ：デフォルトの名無しさん：2008/03/06(木) 23:35:33

>>463
もうおまえはこのスレに来なくていいよ。おまえみたいな奴が一人でもいると、スレが荒れるだけだから。

473 ：デフォルトの名無しさん：2008/03/06(木) 23:37:22

>>464も忘れてたｗ
バチカンとか意味不明な奴もお花畑板いけよw

474 ：デフォルトの名無しさん：2008/03/06(木) 23:39:11

間違えてageちまったじゃねーかよー
どうしてくれるんだ？おい、おまえら！！
>>463-464
おまえら責任とれよな

475 ：デフォルトの名無しさん：2008/03/06(木) 23:40:12

何だこの酔っ払い

476 ：デフォルトの名無しさん：2008/03/06(木) 23:41:22

英語は使えなくても叩くときだけは大張り切りですな。

477 ：デフォルトの名無しさん：2008/03/06(木) 23:48:20

>>464
こういうことは言うのは派遣かニートだろ。
こんな社会のカスは相手にすんなよ。
違うスレでは「ニート達よ団結せよ！」とかいってる奴だからw

478 ：デフォルトの名無しさん：2008/03/06(木) 23:51:25

真・スルー　何もレスせず本当にスルーする。簡単なようで一番難しい。
偽・スルー　みんなにスルーを呼びかける。実はスルーできてない。　　　　　　← >>477
予告スルー　レスしないと予告してからスルーする。
完全スルー　スレに参加すること自体を放棄する。
無理スルー　元の話題がないのに必死でスルーを推奨する。滑稽。
失敗スルー　我慢できずにレスしてしまう。後から「暇だから遊んでやった」などと負け惜しみ。
願いスルー　失敗したレスに対してスルーをお願いする。ある意味３匹目。
激突スルー　話題自体がスルーの話に移行してまう。泥沼状態。
疎開スルー　本スレではスルーできたが、他スレでその話題を出してしまう。見つかると滑稽。
乞食スルー　情報だけもらって雑談はスルーする。
質問スルー　質問をスルーして雑談を続ける。
思い出スルー　攻撃中はスルーして、後日その思い出を語る。
真・自演スルー　議論に負けそうな時、ファビョった後に自演でスルーを呼びかける。
偽・自演スルー　誰も釣られないので、願いスルーのふりをする。狙うは４匹目。
３匹目のスルー　直接的にはスルーしてるが、反応した人に反応してしまう。
４匹目のスルー　３匹目に反応する。以降５匹６匹と続き、激突スルーへ。

479 ：デフォルトの名無しさん：2008/03/06(木) 23:51:43

英語云々以前に、クロージャのネタも深すぎでウザイ
明日も分からない全然決まってもないことだろ
久々にすれ盛り上がってるけど、他にネタないのか
結局は海外のソースに依存することになるんだろうけど、jdk1.8ねたとか、
いまホットなライブラリネタとかないの？

480 ：デフォルトの名無しさん：2008/03/07(金) 00:00:27

>>477
何この必死君

481 ：デフォルトの名無しさん：2008/03/07(金) 00:02:00

>>478
これ初だけど、いつのコピペ？

というかスルー以前（あおりとかあらし以前）に
次世代JavaスレなのにC＃とかC＋＋とかスレ違いじゃないかのか？
C＃とかC＋＋で出来てるだろ、だからJavaでもやれよって論法が多いが、こいつらサルだろｗ

482 ：デフォルトの名無しさん：2008/03/07(金) 00:03:09

>>479
ホットなライブラリ(笑)

483 ：デフォルトの名無しさん：2008/03/07(金) 00:03:40

>>480
いや、バチカンとかぬかす奴よりは、やつの言い分の方が正しい

484 ：デフォルトの名無しさん：2008/03/07(金) 00:05:15

で、「保守の集まり」ってのは一体何のことか説明してくれないか？
おまえ、いつも同じこといってるだろ

485 ：デフォルトの名無しさん：2008/03/07(金) 00:08:32

ここは誰かが JCP の動向を翻訳してくれるのを口を空けて待ってるスレですよ。
たまに自分が判定する側の人間になってると勘違いしてる人もいるようですけど。

486 ：デフォルトの名無しさん：2008/03/07(金) 00:13:31

>>477
このスレ初めて見ただけど、確かにそいつはゴミみたいなやつだな。
というか、そばに同じようなキモイ奴がいるんだよな。
こいつ、何とかしてやってくれよ。

487 ：デフォルトの名無しさん：2008/03/07(金) 00:18:09

> こんな社会のカスは相手にすんなよ
> このスレ初めて見ただけど

わざわざ自爆宣言するの流行ってるの？

488 ：デフォルトの名無しさん：2008/03/07(金) 00:27:52

>>487
スルー出来んのか？おまえもカスだしなｗ

489 ：デフォルトの名無しさん：2008/03/07(金) 00:33:05

次からテンプレに「俺様アイディアの披露禁止」って書いといてくれよ。
いちいち食って掛かるバカが多すぎる。

490 ：デフォルトの名無しさん：2008/03/07(金) 00:33:34

チャットは自粛してくださいな。
知能のある方は以下正常化でよろすく。

491 ：デフォルトの名無しさん：2008/03/07(金) 00:36:25

派遣は明日も早いし5時起きだろ？早く寝ろよｗｗ
ニートはもともと社会のカスだし別にどうでもいいからｗｗｗｗｗ

492 ：デフォルトの名無しさん：2008/03/07(金) 00:40:26

カス達よ団結せよ！

493 ：デフォルトの名無しさん：2008/03/07(金) 00:42:51

>>466
＞見せれるとな。

みせれる？

494 ：デフォルトの名無しさん：2008/03/07(金) 00:47:21

>>492
ワロタｗｗ

495 ：デフォルトの名無しさん：2008/03/07(金) 00:54:49

もう追いかけてないから知らないけど、クロージャの残りの論点は、return, breakをどうするか（表記とかも）ぐらいだろ。

それからscalaとかgooglebyとか勧めてる奴もいるけど、今ならrubyだろうな。
rubyなんて正にモルモンしてるけど、perlほどキチガイじゃない。（上にあったのはバチカンだったか？）

496 ：デフォルトの名無しさん：2008/03/07(金) 00:57:28

このスレひっでえなｗｗｗｗｗ

497 ：デフォルトの名無しさん：2008/03/07(金) 00:59:55

我こそは最前線 Java を追う先駆者と自負されてる方々ばかりですから。

498 ：デフォルトの名無しさん：2008/03/07(金) 01:00:27

Javaの最前線にはひどい人材しかいないようだな

499 ：デフォルトの名無しさん：2008/03/07(金) 01:01:52

＞googleby

多分ネタだろうけど、一瞬googleboyに見えたｗｗｗ

500 ：デフォルトの名無しさん：2008/03/07(金) 01:05:30

>>498
Javaにも最前線にも失礼。
全人類的にこのスレッドは汚物、失礼なものにあたる。

501 ：デフォルトの名無しさん：2008/03/07(金) 01:09:05

>>497
英語は出来ないけどなｗ

502 ：デフォルトの名無しさん：2008/03/07(金) 01:15:28

>>500
早く寝ろよ。派遣先は遠いから明日も早く起きなければいけないんだろ？

503 ：デフォルトの名無しさん：2008/03/07(金) 01:17:42

>>500

全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ
全人類的ｗ

504 ：デフォルトの名無しさん：2008/03/07(金) 01:18:54

Javaの未来は暗いな

505 ：デフォルトの名無しさん：2008/03/07(金) 01:19:20

>>500
おまえは、カマキリでも食っちまったんじゃないか？

506 ：デフォルトの名無しさん：2008/03/07(金) 01:23:43

IDが無くてもageてるのは同一人物だろうな・・・

jdk7の次のビルドでも出てくれば少しは矛先が変わるのになぁ。
12月からビルド止まったままだし・・・

507 ：デフォルトの名無しさん：2008/03/07(金) 01:28:23

全人類的とかいってる奴、あと保守でモルモン経典うんちゃらとかぬかしてる奴も
一緒に死ねよ。もうおまえの負けだな。

はよオナニーして寝ろｗ

508 ：デフォルトの名無しさん：2008/03/07(金) 01:29:22

506のアドバイスでsage付けるようにしたのか

509 ：デフォルトの名無しさん：2008/03/07(金) 01:30:08

まずID制の導入を嘆願するところから始めなきゃならんな

510 ：デフォルトの名無しさん：2008/03/07(金) 01:36:20

また荒らしか。

511 ：デフォルトの名無しさん：2008/03/07(金) 01:37:44

>>508-510
はよオナニーして寝ろYO

512 ：デフォルトの名無しさん：2008/03/07(金) 01:44:17

ID無くてもBooでがいしゅつになるかで同一チェックできるんじゃないかと思えてきた。

513 ：デフォルトの名無しさん：2008/03/07(金) 01:57:05

>>512
誰だおまえ？

514 ：デフォルトの名無しさん：2008/03/07(金) 02:01:03

>>513
これが噂の負け組みの人だから、かまっちゃダメ！！

515 ：デフォルトの名無しさん：2008/03/07(金) 02:03:03

516 ：デフォルトの名無しさん：2008/03/07(金) 02:30:30

こんなところにも負け組みの人が漂流してるんですね（笑い）

517 ：デフォルトの名無しさん：2008/03/07(金) 02:31:37

ID、IDってうるさい人、あなたも負けたんですか（笑い）

518 ：デフォルトの名無しさん：2008/03/07(金) 02:37:45

ちょっとわからないことがあるのですが、
ゴズリンさんいますか？

519 ：デフォルトの名無しさん：2008/03/07(金) 03:27:18

今日の夜は長いですねｗ
冶金お疲れ様っす！！

520 ：デフォルトの名無しさん：2008/03/07(金) 08:09:52

>>495
Scalaは中の人の議論でもよく出てくる言語だよ。
やっぱりよく出来てる。使ってねーけどw

521 ：デフォルトの名無しさん：2008/03/07(金) 08:16:56

Control invocation syntaxで算術ifも書けるね。うれしい。

522 ：デフォルトの名無しさん：2008/03/07(金) 15:55:38

>>520
使えば分かるよ。Javaから見れば何でもありだからｗ

523 ：デフォルトの名無しさん：2008/03/07(金) 19:51:10

ニート達はもうどっか行っちまったか？

524 ：デフォルトの名無しさん：2008/03/07(金) 22:44:28

ニート、ニートってうるさいんだよ！Java使ったってC＃使ったっていいだろ！！！

525 ：デフォルトの名無しさん：2008/03/07(金) 22:52:21

何この自演ｸｾｰの

526 ：デフォルトの名無しさん：2008/03/08(土) 00:19:40

派遣はいていいですか（・＿・）

527 ：デフォルトの名無しさん：2008/03/08(土) 01:09:17

>>525
ニート乙

528 ：デフォルトの名無しさん：2008/03/08(土) 01:10:46

図星だったか…

529 ：デフォルトの名無しさん：2008/03/08(土) 11:59:23

派遣はいていいですか（・＿・）

530 ：デフォルトの名無しさん：2008/03/08(土) 12:51:33

しつけーよｗいいよ！いていいよｗ、むしろお願いするｗ

531 ：デフォルトの名無しさん：2008/03/08(土) 13:15:38

派遣はいてないですか！？

532 ：デフォルトの名無しさん：2008/03/08(土) 17:01:22

>>530
ニートなんですが…ボクちんもいいですか（・＝・）

533 ：デフォルトの名無しさん：2008/03/08(土) 22:44:17

>>530
誰だってJava使っていいですよね？

534 ：デフォルトの名無しさん：2008/03/09(日) 11:44:37

>>522
何でもできるとかそんなことじゃなくて、すごく良く設計されている。

535 ：デフォルトの名無しさん：2008/03/09(日) 15:38:37

>>534
ボクちんニートなんですが…

536 ：デフォルトの名無しさん：2008/03/09(日) 22:07:15

rubyとscalaの大きな違いは、JavaVM上で動かすことを前提にしているかどうかだな。

537 ：デフォルトの名無しさん：2008/03/09(日) 22:25:37

馬鹿そう…

538 ：デフォルトの名無しさん：2008/03/10(月) 01:34:42

>>478
> 激突スルー

539 ：デフォルトの名無しさん：2008/03/11(火) 11:37:58

どう使うかに絞った簡単な解説
Closures for Java
http://jazoon.com/download/presentations/1680.pdf

540 ：デフォルトの名無しさん：2008/03/11(火) 19:49:32

ふと思った。例に出てくる for each とかで

for each (String name, Thing thing : myMap) {
　　if (thing.isCocksucker()) {
　　　　return;　　　　　　　　　　　　// ← ｺｲｼはどこに return するのかね？
　　}
　　doSomething(name, thing);
}

541 ：デフォルトの名無しさん：2008/03/11(火) 19:57:15

for eachの置かれているメソッドから抜ける。

542 ：デフォルトの名無しさん：2008/03/11(火) 20:24:55

>>540
>>540
>>540
>>540

543 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/11(火) 20:57:59

クロージャより関数オブジェクトとか関数リテラルみたいなラムダの方が欲しいんだけどなぁ。

545 ：デフォルトの名無しさん：2008/03/11(火) 21:32:42

>>544
クロージャと、関数オブジェクトとか関数リテラルみたいなラムダとの違いって？

546 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/11(火) 23:16:07

>>546
それだと順番間違えやすいし、順番間違えてもコンパイル時にチェックできないから
実行時に変な動作してから初めて気付く事になるような……

548 ：デフォルトの名無しさん：2008/03/12(水) 01:37:02

じゃあブロック引数は一つの関数にすればいいんじゃないの？
変な人。

549 ：デフォルトの名無しさん：2008/03/12(水) 08:09:04

それじゃ>>543と変わらん

550 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/12(水) 12:03:38

クロージャってこういう呼び出し方出来ないんだろうか・・・。
({arg => hogehoge})(arg);

552 ：デフォルトの名無しさん：2008/03/12(水) 12:06:59

クロージャーよりもやっつけで盛り込んだ既存のライブラリ仕様を洗練させて欲しいんだが。

553 ：デフォルトの名無しさん：2008/03/12(水) 12:34:23

>>551
BGGA v0.5にはない。

554 ：デフォルトの名無しさん：2008/03/12(水) 12:34:44

洗練って・・・
下位互換考えるともう変更できんだろ・・

555 ：デフォルトの名無しさん：2008/03/12(水) 12:37:22

>>551
それだと単なるキャストだね。
argがクラス名と変数名/フィールド名で重複してるけど。

556 ：デフォルトの名無しさん：2008/03/12(水) 12:39:02

>>552
openjdkあたりにパッチ送れば？ acceptされるとは限らんけど。

557 ：デフォルトの名無しさん：2008/03/12(水) 12:43:30

というか勝手にクラスライブラリ作ればいい。
将来採用されることもありうる。

558 ：デフォルトの名無しさん：2008/03/12(水) 13:50:47

必要になれば、Cのtypedefみたいなのでもっとパワーアップしてるのがサポートされるんじゃないか。
タイプ量が多いとかはエイリアスで解決できるわけで、クロージャの言語仕様とは全く関係ない。
といいつつもJavaではtypedefみたいのは永遠とサポートされないと思うけど。

559 ：デフォルトの名無しさん：2008/03/12(水) 14:21:24

typedefとマクロはないだろうな

560 ：デフォルトの名無しさん：2008/03/12(水) 15:14:22

JavaFX はどうなったのさ。

561 ：デフォルトの名無しさん：2008/03/12(水) 16:00:16

>>558
ヘッダファイルを使うC言語と違って、
Javaのコンパイル単位はtypedefと相性悪いでしょ。
publicクラス毎に、何回も同じtypedefを書く必要出てくるし。

あと、typedef入れるより型推論が入った方が嬉しいぞ。

562 ：デフォルトの名無しさん：2008/03/12(水) 17:09:38

Cのtypedefのパワーアップとして考えられるのは、文字通りtype definedのこと。
型推論と似てるけど、型推論は動的にやるでしょｗ

もしあるなら、typedefは静的におこなわれる、型(class)別名で、
変数のようにスコープを持つとかなら、
CやC++ templeteのようにバグとか追跡不可能で
エラーメッセージも意味不明にまでなったりしないと思う。

だから、やっぱり長いしタイプ量が変わんないじゃんというのは分かるけど、
タイプ量が多いのとクロージャとは関係ない。

563 ：デフォルトの名無しさん：2008/03/12(水) 17:13:03

今やるならアノテーションになるけど、
結局はtypedefやりたいならアノテーションつかってツール作って自分でやってくれよってなるんじゃないか。

564 ：デフォルトの名無しさん：2008/03/12(水) 17:16:42

Adaのtypedefならいいわけか

565 ：デフォルトの名無しさん：2008/03/12(水) 17:56:30

typedefというよりも、別名（エイリアス）ってのがあればいいってわけだ

566 ：デフォルトの名無しさん：2008/03/12(水) 18:25:48

>>562
タイプ量が多いのとクロージャは関係ないよ。
タイプ量が多いと builderパターン+クロージャで
リスナを生成するのが面倒くさいってだけで。

それに別名定義できても、C言語のヘッダファイルみたいなものがないと
それほど便利にはならないっしょ。それよりは型推論の方がいいって事。
型推論も別名定義も両方あってもいいけどさ。

567 ：デフォルトの名無しさん：2008/03/12(水) 18:35:57

そーいや、>>45には type aliasingあるけど、これも続報ないからどーなってんのかわからんね。

もっとも、これは generics でバカみたいに長くなった型名を短くてわかりやすいものにするのが
主な目的っぽいから、>>550 みたいに generics使ってない上に、
MouseListenerBuilder やら setMouseClickled やら MouseEvent やらの
個々の識別子は長すぎて読み易さを低下させてる、ってわけでもないのに
使うようなモンでもねーと思うが。

568 ：デフォルトの名無しさん：2008/03/12(水) 18:47:24

もういっそプリプロセッサがあれば良いんじゃね？

569 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/12(水) 19:24:45

> addMouseListener(new MLB().sMC({MouseEvent e => System.out.println("clicked"); }));
なにこれ

571 ：デフォルトの名無しさん：2008/03/12(水) 19:30:27

>>570
よーするに、可読性落とさないような名前が思いつかないなら
>>550のタイプ量は妥当だって事。

572 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/12(水) 21:42:20

別にクロージャーが入っても何か新しいことが出来るようになったり
下らないミスが減ったりするわけじゃないんでしょ。拡張 for 並みに
どうでもいいんだけど。

574 ：デフォルトの名無しさん：2008/03/12(水) 21:43:13

>>572
エイリアスやらマクロやらプリプロセッサやら出してくるぐらいなら、そっちのがいいね

575 ：デフォルトの名無しさん：2008/03/12(水) 22:01:29

拡張forは便利だろ。
いちいちインデクサなんて書いてられるか可読性も落ちる。

576 ：デフォルトの名無しさん：2008/03/12(水) 22:04:29

インデクサ？ Iterator の間違いじゃね？

577 ：デフォルトの名無しさん：2008/03/12(水) 22:10:25

javax書き換えられないようなsuperpackageはいらない、Sunの失態が無いなら良いけど

578 ：デフォルトの名無しさん：2008/03/12(水) 23:00:42

↑ん？どういうこと？

579 ：デフォルトの名無しさん：2008/03/12(水) 23:01:12

>>575
C#に洗脳されすぎｗ

580 ：デフォルトの名無しさん：2008/03/12(水) 23:03:18

クラスとかメソッド名が長いってだけなら、ビルダークラスとかを継承してオーバーライドして自分で短い名前にしてくれよ。
それぐらい頭使え。

581 ：デフォルトの名無しさん：2008/03/12(水) 23:12:34

void hoge(a){actionPerformed(a);]
で、短いメソッド名で実装して、それを呼び出すことね。

582 ：デフォルトの名無しさん：2008/03/12(水) 23:26:28

indexerって普通の英語なんだが。

583 ：デフォルトの名無しさん：2008/03/12(水) 23:30:00

Javaじゃそんな言葉使わんしここ日本。

584 ：デフォルトの名無しさん：2008/03/12(水) 23:31:02

普通の英語って事は「索引を作る人」って意味で使ってるとか？

585 ：デフォルトの名無しさん：2008/03/13(木) 00:02:39

>>583
お前は日本語でプログラム書くのか？

586 ：デフォルトの名無しさん：2008/03/13(木) 00:16:46

演算子オーバーロードが言語仕様にあれば
Javaでもインデクサって普通に呼ぶだろうね。

Javaもinterface経由で演算子オーバーロードに対応したらいいのに。
AppendableとかCalculateableみたく、目的を明示すれば設計者も馬鹿しないでしょ。

587 ：デフォルトの名無しさん：2008/03/13(木) 00:21:01

演算子オーバーロードは絶対にサポートしないといってたけど。

588 ：デフォルトの名無しさん：2008/03/13(木) 00:28:40

>>585
いやいや、言いたいのは話をわざわざ分かりにくくするために英語にする必要はないだろうということ。

589 ：デフォルトの名無しさん：2008/03/13(木) 00:33:24

C#ちゃんはいいかげんに巣に帰れよ

590 ：デフォルトの名無しさん：2008/03/13(木) 02:05:45

インデクサくらい理解してやってくれ。

ループ抽象(拡張for)
コントロール・インヴォケイション・シンタックス

は過激に便利ですよ。>>539のp4-6見てください。
プログラム構造がかなりすっきりまとまります。
プログラム内でのコードの共通化も進みますし。

591 ：デフォルトの名無しさん：2008/03/13(木) 03:43:59

↑もうこなくていいから。死んでくれ

592 ：デフォルトの名無しさん：2008/03/13(木) 06:40:12

病的な過剰反応だな。明らかにネットに向いてない。

593 ：デフォルトの名無しさん：2008/03/13(木) 14:00:38

>>592
おまえも

594 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/03/13(木) 22:49:58

>>594
それをやるには static import とは別の仕組みが必要になるし、
どうせやるなら class Alias みたいなものをヘッダファイルモドキとして使うのは間抜けすぎる。

596 ：デフォルトの名無しさん：2008/03/13(木) 23:59:35

>>595
それ言っちゃおしまいでしょ。
java.lang.Math とか java.util.Collections とか、
クラス外にメソッド置いとけるんならクラス外に置きたいようなのは標準APIにも多いし。

Java でやるなら >>594 みたいなやり方しかないと思うけどね。

597 ：デフォルトの名無しさん：2008/03/14(金) 00:01:58

>>562
> 型推論と似てるけど、型推論は動的にやるでしょｗ

MLなどの型推論はコンパイル時に静的にやるよ。
動的だったら、型を推論するまでもなくチェックすればいい。

>>567が言っているような、
generics使って汎用に書かれたクラスに、
具体的なクラスを与えて、新たなクラスとしてpublicにする、
って機能は必須だと思う。

ただconcept(C++), type class(haskell)のような形の方が
より汎用でスマートだと思う。単なるエイリアスじゃなくて
両クラスのグルーとなるコードも加えられるし。

598 ：デフォルトの名無しさん：2008/03/14(金) 00:05:28

>>596
クラス外メソッド定義とクラスエイリアスは別件。

599 ：デフォルトの名無しさん：2008/03/14(金) 00:15:29

>>598
クラス外メソッド定義したいって言ってるんじゃなくて
言語仕様が許すなら必ずしもクラス内に置く必要ないエイリアスやメソッドを
クラス内に置かなきゃいけないのは等しくアレだって事

600 ：デフォルトの名無しさん：2008/03/14(金) 02:39:52

アノテーションでいいよ。機能的には違うけど、本質的に同じだし。

601 ：デフォルトの名無しさん：2008/03/14(金) 03:01:16

クロージャーなんて既存機能で十分まかなえるものの焼き直しなんかより
もっと AOP 的設計が出来るようなアプローチしろよ。インスタンスフィールドへの
アクセスもトラップできるようにすればそもそもプロパティ拡張もいらんだろが。

602 ：デフォルトの名無しさん：2008/03/14(金) 03:44:37

クロージャで演算子オーバーロードもとラップできるといいけどな

603 ：デフォルトの名無しさん：2008/03/14(金) 05:49:16

> インスタンスフィールドへのアクセスもトラップできるようにすれば
フィールドアクセスがめちゃくちゃ遅くなりそうだな

604 ：デフォルトの名無しさん：2008/03/14(金) 06:29:16

final 宣言されてない getter/setter と同等にできるだろ。めちゃくちゃの根拠が不明。
まぁプロパティアクセスに関しては「後で」「静的に」「他のソースを修正せずに」アクセサを
追加できれば十分だが。

605 ：デフォルトの名無しさん：2008/03/14(金) 06:51:54

また変な奴が常任してしまったな。

606 ：デフォルトの名無しさん：2008/03/14(金) 06:54:17

ＪＳ乙

607 ：デフォルトの名無しさん：2008/03/14(金) 07:11:52

C#厨房よりはましｗ

608 ：デフォルトの名無しさん：2008/03/14(金) 07:28:45

というかおまえ誰だよ

609 ：デフォルトの名無しさん：2008/03/14(金) 07:33:04

俺ビルジョイ

610 ：デフォルトの名無しさん：2008/03/14(金) 07:58:33

ＪＳじゃイニシャル違うじゃんかよ

611 ：デフォルトの名無しさん：2008/03/14(金) 10:58:17

>>604
そか？隠蔽されたフィールドに対するアクセスとかも考えたら
プロパティモドキじゃ対応できないし馬鹿みたいにでかい仕組みが必要になると思うが。

612 ：デフォルトの名無しさん：2008/03/14(金) 12:18:31

JKが女子高生なんだからJSは・・・

613 ：デフォルトの名無しさん：2008/03/14(金) 12:22:35

専門学校生だよね

614 ：デフォルトの名無しさん：2008/03/14(金) 12:30:48

>>611
それだけなら何とかなると思うが……

もっとも、リフレクション対応までして「インスタンスフィールドアクセスのトラップ」
できるようにするより他の事にエネルギー使って欲しいぞ。

615 ：デフォルトの名無しさん：2008/03/14(金) 15:49:59

J 常識的に
S ｾｯｸﾙして

616 ：デフォルトの名無しさん：2008/03/14(金) 16:03:51

>>611
現時点でも少なくともリフレクション程度は確保できる。
まぁフィールドアクセスはそれも包含できるという意味で引き合いに出しただけで本意は別。
ゴリゴリ書くしかなかったのを簡素化したいのはもっともだが、なら無名内部クラスより
DI の標準様式一つでも考慮しろと。

617 ：デフォルトの名無しさん：2008/03/14(金) 16:14:40

> DI の標準様式一つでも考慮しろと。
？

618 ：デフォルトの名無しさん：2008/03/15(土) 01:41:01

あれ？JFileChooserが遅いバグって6u5までのどこかで修正入った？

619 ：デフォルトの名無しさん：2008/03/15(土) 10:17:10

>>541
つーか選択肢は二つくらい(?)あって
　・クロージャから抜けるのみ・・ >>540のコードなら、doSomething() が実行されないだけで for each は続く
　・for each の置かれているメソッドから抜ける
「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら
前者が選ばれるだろうなと思ってさ。

620 ：デフォルトの名無しさん：2008/03/15(土) 10:19:34

>>619
> 「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら

違う。

621 ：デフォルトの名無しさん：2008/03/15(土) 10:32:19

匿名クラスの構文糖って言いたかったんかな

622 ：デフォルトの名無しさん：2008/03/15(土) 11:45:56

クロージャのreturn周りはどうなるのかホントわかんないな。
ECMAScript風になるのか、ruby風になるのか。

623 ：デフォルトの名無しさん：2008/03/15(土) 11:54:42

C#風に、内容に expression しか書けないクロージャ（ラムダ式）と、
statements が書けるクロージャの2種類作るってのもアリだと思うんだけど。

624 ：デフォルトの名無しさん：2008/03/15(土) 11:54:49

どっちでもない

625 ：デフォルトの名無しさん：2008/03/15(土) 12:41:25

ruby風はありえないだろ

何がどこに抜けるんだかバージョンによって変わるだなんて

626 ：デフォルトの名無しさん：2008/03/15(土) 13:29:50

returnで脱出する最外レベルはメソッドであって、
クロージャやブロックではない。
詳しくは http://www.javac.info/closures-v05.html を読め。

627 ：デフォルトの名無しさん：2008/03/31(月) 04:07:09

Listenerを登録するという設計自体がクロージャと相性が悪いわけか
なんでこんな設計にしたんだ

628 ：デフォルトの名無しさん：2008/03/31(月) 04:15:55

他に手がないからだろ

629 ：デフォルトの名無しさん：2008/04/01(火) 08:58:11

>>627
てか他に手は無いだろ

630 ：デフォルトの名無しさん：2008/04/02(水) 02:03:03

>>627
相性が悪いって程でもないと思うが
確かBGGAでは、function typeをListenerに暗黙に変換するための
仕掛けが用意されるんじゃなかったっけか

631 ：デフォルトの名無しさん：2008/04/02(水) 09:54:37

>>630
ActionListenerみたいにメソッド一個しか無い場合は変換できるけど、
BGGAには、MouseListenerみたいにメソッドいっぱいある場合の変換の仕掛けはないよ。
named inner methodがあるFCM と比べると、BGGAとXxxListenerは相性悪い。

632 ：デフォルトの名無しさん：2008/04/02(水) 10:02:50

http://tronicek.blogspot.com/2008/03/method-references-version-2008-03-17.html
method reference だそーです。

method reference に '#' 使うのが平気な感覚もってるのに
accessing property に '.' 以外の演算子使うのってダメなんかねぇ…… と思ったり。

633 ：デフォルトの名無しさん：2008/04/02(水) 10:50:41

listOfArgumentTypesは必要かね?
継承に絡まない型推論はしない主義だから必要になるのかな。
文脈は常に強く型付けされているはずだが。

634 ：デフォルトの名無しさん：2008/04/02(水) 10:59:04

もう Method の静的解決 (Foo.class みたいな) でええやん。関数ポインタみたく使えりゃええんじゃろ。

635 ：デフォルトの名無しさん：2008/04/02(水) 11:00:07

static import で listOfArgumentTypes 書けるようにしてくれませんかね？

636 ：デフォルトの名無しさん：2008/04/02(水) 19:35:24

>>633
本来なら通常は要らんと思うけど、同名のメソッドがオーバーロードされてる
場合必要になるから、必須にしてるんじゃないかな？

637 ：デフォルトの名無しさん：2008/04/02(水) 19:41:39

それは型情報で分かるから。

638 ：デフォルトの名無しさん：2008/04/02(水) 20:49:02

>>634
ちがうよ。変数スコープが重要

639 ：デフォルトの名無しさん：2008/04/02(水) 21:46:47

>>637
contravariant な変換許すなら、型情報だけから必ず判るわけじゃないから
listOfArgumentTypes 省略しないタイプも必要だと思うぞ。

省略できても良いと思うけど。

640 ：デフォルトの名無しさん：2008/04/02(水) 23:01:51

>>637
(System.out#println(String)).invoke("Foo")
みたいな場合を考えると必要なケースもあるよってこと
もちろん、必要じゃないケースもあるから省略はできてもいいと思う
もちろん、上のような式を実際に書く必要はないだろうけど、文法上
書けるなら対策は必要になるわけだ

641 ：デフォルトの名無しさん：2008/04/09(水) 23:28:18

そろそろjdk1.7はリリースされるの？

642 ：デフォルトの名無しさん：2008/04/10(木) 00:19:26

来年の始め頃じゃないか

643 ：デフォルトの名無しさん：2008/04/10(木) 00:27:41

1.6updateN が出てから 1年ぐらいは必要じゃないかと思うが

644 ：デフォルトの名無しさん：2008/04/10(木) 09:45:57

なんだ。まだか。

645 ：デフォルトの名無しさん：2008/04/10(木) 21:34:28

Java7からと思ってたが、Java KernelはUpdate Nから入るのね。
JMFあたりも自動ダウンロードしてくれるならありがたい限りだけどどうだろ。

646 ：デフォルトの名無しさん：2008/04/18(金) 12:48:24

JDK7 build25
http://download.java.net/jdk7/changes/jdk7-b25.html
http://download.java.net/jdk7/binaries/

647 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/04/19(土) 08:59:28

それは既に入る予定だが?
しかもクロージャを使って。

649 ：デフォルトの名無しさん：2008/04/19(土) 09:30:50

>>647
つ control invocation syntax

650 ：デフォルトの名無しさん：2008/04/24(木) 14:22:07

次のjava7でクロージャ以外で主要な目玉機能ってなんですか？

651 ：デフォルトの名無しさん：2008/04/24(木) 16:03:13

俺はダグ・リー先生のjsr166y.forkjoinがどうなるかが最大の関心事
素晴らしすぎ。

652 ：デフォルトの名無しさん：2008/04/24(木) 16:21:19

今度の JavaOne で dolphin の進捗も発表されんじゃね？

653 ：デフォルトの名無しさん：2008/04/24(木) 17:00:32

クロージャ以外は特にないよ

654 ：デフォルトの名無しさん：2008/04/24(木) 20:05:44

fork-joinはメニーコア時代の必需品になるだろうし重要だと思う。
そんな時代だと永続性ユニットとしてRDBMSだけじゃなく、
これとMemoryMappedFileあたりと組み合わせたやつとか使いそう。

655 ：デフォルトの名無しさん：2008/04/24(木) 21:35:45

FileじゃなくてOODBください　＞＜；

656 ：デフォルトの名無しさん：2008/04/27(日) 15:47:45

いつまでも実現しないMVMは？

657 ：デフォルトの名無しさん：2008/04/29(火) 15:06:35

JDK7 build26
http://download.java.net/jdk7/changes/jdk7-b26.html
http://download.java.net/jdk7/binaries/

658 ：デフォルトの名無しさん：2008/05/04(日) 23:56:54

LINQみたいなのは、はいらんの？
quaereのような式言語っぽいやつじゃなくて言語実装として組み込まれてるのがほしい。

659 ：デフォルトの名無しさん：2008/05/05(月) 00:12:37

スクリプト関連ほんとに追加されるのかな～

660 ：デフォルトの名無しさん：2008/05/13(火) 03:23:42

スクリプト関連は、やるだろうね。
Java一本が難しくなった今、他言語のサポートは急務
LINQみたいなのは、能力的に無理そう。

661 ：デフォルトの名無しさん：2008/05/16(金) 19:50:57

method refarenceなかなかいいんじゃないの？
Integer#parseInt(String);のやつ

662 ：デフォルトの名無しさん：2008/05/20(火) 00:41:53

JavaFXをプッシュしてるけどSunは、まともなオーサリングツール作る気あるのか？
どう考えても負け戦な気がするんだけど。

663 ：デフォルトの名無しさん：2008/05/20(火) 01:24:56

君にはまだ早すぎる。できる開発者だけの楽しみだしｗ

664 ：デフォルトの名無しさん：2008/05/20(火) 23:38:25

負け戦は確定でしょ
ただでさえ中心人物がどんどんやめていってるのに

665 ：デフォルトの名無しさん：2008/05/21(水) 15:16:25

SUNは、開発者ごとJavaFXをGoogleにあげればいいと思うよ。
開発者のやる気も出るし、Android標準搭載になっていい事だらけだと思うぞ。

まあもらってくれないだろうが・・・

666 ：デフォルトの名無しさん：2008/05/21(水) 23:37:07

JavaFXって結局ブラウザの中でも実行できるんだっけ？
デモサイトを見てもブラウザ内で実行できるのが無いんだけど単にJavaFXのブラウザプラグインがまだ無いだけ？

667 ：デフォルトの名無しさん：2008/05/21(水) 23:43:12

全部javaで書いてあります。> JavaFX

668 ：デフォルトの名無しさん：2008/05/21(水) 23:47:01

えーとね、スクリプトをサポートする順番は、sunの発表では、rubyとかはあるけどFXは全く予定にないってところだった。
まだ熟してないんだよ。そーあせるなってｗ

669 ：デフォルトの名無しさん：2008/05/22(木) 00:18:10

熟すときは来るのか？ｗ

670 ：デフォルトの名無しさん：2008/05/22(木) 07:10:25

SM次第でSMのシルバーなんとkがが市場を開拓すればおのずと、
知らないだろうけど、フォトランのsun風味とかもあるし、

671 ：デフォルトの名無しさん：2008/05/23(金) 11:09:35

JDK7 build27
http://download.java.net/jdk7/changes/jdk7-b27.html
http://download.java.net/jdk7/binaries/

672 ：デフォルトの名無しさん：2008/05/26(月) 12:02:22

JDK6でせっかく入れたTools APIはjava7のリッチクライアントプロファイルでは外されるんだな。
Tools APIってJDK6で入っただけでまだ標準ライブラリ化してないんだっけ？

673 ：デフォルトの名無しさん：2008/05/26(月) 12:09:04

>>672
リッチクライアントプロファイルからはjavacとか削るつもりなんだろ。

プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。
だからTools APIが削られる事と標準かどうかは関係ない。

674 ：デフォルトの名無しさん：2008/05/26(月) 13:47:38

プロファイルはJREの話だからjavacがないのは元からだ。
toolsAPIはJREのrt.jarに入ってるから削られる。

675 ：デフォルトの名無しさん：2008/05/26(月) 14:18:04

>>674
このスレの主だから。こいつは、なんつーか傲慢で非常にひねくれた性格なのよｗ
確かageたりすると、こいつ、すぐ発狂するからｗｗ

676 ：デフォルトの名無しさん：2008/05/26(月) 14:20:08

＞プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。
だからTools APIが削られる事と標準かどうかは関係ない。

この「だから」ってのはどうつながっていて、標準ライブラリとTools APIとどういう風に「関係がない」のかちゃんと説明できるの？
偉そうに適当な事ばかり言ってないでさ

677 ：デフォルトの名無しさん：2008/05/26(月) 14:39:12

AWT/Swingが削られるのはヘッドレスプロファイルだろ。サーバーサイド向け。
けどjava2Dの一部ってAWTだよな・・・。

678 ：デフォルトの名無しさん：2008/05/26(月) 14:54:49

headless はマジで助かる。
Ubuntuにheadlessのopenjdkが入って助かった。
でないとサーバ用途なのに、画面周りが必要だったり困りもの。

679 ：デフォルトの名無しさん：2008/05/26(月) 14:59:42

1.4以降なら -Djava.awt.headless=true つけりゃヘッドレスモードになったような。

680 ：デフォルトの名無しさん：2008/05/26(月) 15:00:26

Ubuntuはもうjdk6u10入ってるのか。
新java-pluginって単にJavaFXでブラウザからドッカブルにしたかっただけだよね。
J++が吐いた糞バイトコード食ってブラウザ毎VMおとされる心配がなくなったから良いが。

681 ：デフォルトの名無しさん：2008/05/26(月) 15:09:12

>>679
ん、そうなんだけど、インストール時はdependencyの関係上画面周りの
インストールが必要だったのよ。使わないのに。

682 ：デフォルトの名無しさん：2008/05/27(火) 19:24:21

このスレにもageると発狂する奴がいるのか？

683 ：デフォルトの名無しさん：2008/05/27(火) 20:13:57

研究室も貧乏臭くて真っ暗なんじゃね？図星だろうｗｗ

684 ：デフォルトの名無しさん：2008/05/28(水) 19:35:25

研究室にテロでも仕掛けるのか？
自分でまねいた種だし、いっちょやっつけちゃってよｗｗ

685 ：デフォルトの名無しさん：2008/06/01(日) 16:29:28

研究室にテコを仕掛けてきますた。
見事に釣り合っております。

686 ：デフォルトの名無しさん：2008/06/06(金) 19:12:40

JDK7 build28
http://download.java.net/jdk7/changes/jdk7-b28.html
http://download.java.net/jdk7/binaries/

687 ：デフォルトの名無しさん：2008/06/07(土) 07:16:41

教えて君ですまない。
build28というのはどのくらいの進捗なの？
クロージャやプロパティは使えるようになってますか？

688 ：デフォルトの名無しさん：2008/06/07(土) 08:00:59

> build28というのはどのくらいの進捗なの？
まだまだ。

> クロージャやプロパティは使えるようになってますか？
なってない。

689 ：デフォルトの名無しさん：2008/06/07(土) 08:02:52

>>687
クロージャ使いたかったら http://www.javac.info/ のプロトタイプ使うのが手っ取り早い。

690 ：デフォルトの名無しさん：2008/06/07(土) 12:06:41

>>688-689
ありがとう。それは残念、待ち遠しいですね。

691 ：デフォルトの名無しさん：2008/06/07(土) 14:56:19

別にイラネ

692 ：デフォルトの名無しさん：2008/06/12(木) 16:02:03

多値関数がホスィ

693 ：デフォルトの名無しさん：2008/06/12(木) 17:43:41

俺も思う
配列で実現する
シンタックスシュガーでいいんだけどな・・・

( String a, String b ) = hoge( c);
が書きたいだけなんだ・・・
Object[] hoge(String c){
}
で定義する、でもいいから・・・

694 ：デフォルトの名無しさん：2008/06/12(木) 18:45:55

バグの温床なので諦めて下さい

695 ：デフォルトの名無しさん：2008/06/12(木) 18:59:38

>>694
どの辺がバグの温床？

696 ：デフォルトの名無しさん：2008/06/12(木) 21:14:57

javascriptでもできるようになったんだよな。
var [a, b] = (function (a, b){returen [a, a + b]})(10, 20);

って・・・。

697 ：デフォルトの名無しさん：2008/06/12(木) 22:44:05

多値とオプション値型は、
ヒープを消費しない形で多用したいので、
組み込みで入れて欲しい。

698 ：デフォルトの名無しさん：2008/06/12(木) 23:54:09

>>697
スタック使うのは、何年か前にBugDatabaseでVMの大幅な変更が必要だから却下って言われてたような。

699 ：デフォルトの名無しさん：2008/06/13(金) 00:54:28

VMって、戻り値に複数スタック渡せないんだっけ？

700 ：デフォルトの名無しさん：2008/06/13(金) 07:13:10

無理

701 ：デフォルトの名無しさん：2008/06/13(金) 10:27:13

多値だけは止めてくれ吐き気がする

あれは本当にたちが悪い

702 ：デフォルトの名無しさん：2008/06/13(金) 10:27:38

VMは戻り値指定にひとつの型しか指定できないし、戻り値を返す命令もireturn lreturn freturnみたいな単一の型指定しかできないので、最低限、戻り値指定と複合return命令を追加する必要がある。

703 ：デフォルトの名無しさん：2008/06/13(金) 10:36:46

invokedynamicでも入るんだから何でも入りそう。

704 ：デフォルトの名無しさん：2008/06/13(金) 11:37:27

invokedynamicと戻り値指定変更の影響範囲の違いもわからないのか。

705 ：デフォルトの名無しさん：2008/06/13(金) 11:51:59

実行時にはa,i,l,f,d,voidしか区別する必要ないんだから、
結構簡単なんじゃないの?

706 ：デフォルトの名無しさん：2008/06/13(金) 12:30:28

じゃあおまえがプロトタイプを作って見せてくれ

707 ：デフォルトの名無しさん：2008/06/13(金) 12:45:29

コンパイラの方も多値は基本的に代入だけだしね。

708 ：デフォルトの名無しさん：2008/06/13(金) 13:06:16

いや、だから、コンパイラが返値をObject[] に変えてくれればいいんですお。
配列の返値はOKですよね？

709 ：デフォルトの名無しさん：2008/06/13(金) 13:12:01

オプション型は、論理型への暗黙の変換か、
match case文がないとダサダサだね。
Javaには入りづらいだろうね。

710 ：デフォルトの名無しさん：2008/06/13(金) 13:30:19

>>705
戻り値の数と組み合わせの管理が必要になるだろ。

711 ：デフォルトの名無しさん：2008/06/13(金) 13:35:23

引数の参照渡しと多値関数どちらかとれといわれたらどっちがいい？

712 ：デフォルトの名無しさん：2008/06/13(金) 13:38:09

どっちもイラネ。
case節で指定できる型を増やしてくれ

713 ：デフォルトの名無しさん：2008/06/13(金) 13:38:22

>>710
それはコンパイル時に終わらないかな?
*loadのスロット参照すればいいから。

714 ：デフォルトの名無しさん：2008/06/13(金) 13:58:13

> *loadのスロット参照すればいいから。
バイトコードベリファイア書き換えないと無理ね。
変更後のバイトコードベリファイアに脆弱性ないかを調べるの面倒だし。

あと、スタックフレームが連続してる保障ないはずだから、
*loadでやるのが可能なのかも疑問だったりする。

715 ：デフォルトの名無しさん：2008/06/13(金) 14:53:31

>>714
連続してなくても＊loadで参照できればいいんじゃないのかな。
コンパイル時にフレームサイズもindexも決まるわけだし。
ベリファイア書き換えはちょっと面倒だね。
invokedynamicみたいな基本ポリシーy面での変更はないけれど。

716 ：デフォルトの名無しさん：2008/06/13(金) 15:08:26

> 連続してなくても＊loadで参照でき
るようにするためには、VMの書き換えが必要になるわけで。

717 ：デフォルトの名無しさん：2008/06/13(金) 15:41:36

というか基本的にフレーム内は連続してる前提でしょ。
もちろん実装に任されているけれど。

多値だって個数はスタティックに決まるんだからフレーム内におさめられるし。
>>714は何が疑問なんだろ。

718 ：デフォルトの名無しさん：2008/06/13(金) 15:44:58

>>717
VM仕様で、異なるメソッドでフレームが連続していなければならないって記述してある箇所あんの？

719 ：デフォルトの名無しさん：2008/06/13(金) 16:01:11

>>718
*returnしたものが、*storeなどで参照できるってことだけだね。
多値が追加されたとしても、その辺の抽象的なVMの定義は変らないのでは。

720 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/06/13(金) 16:03:36

>>708
Arrayだとdoubleとか入れるの困るじゃん

722 ：デフォルトの名無しさん：2008/06/13(金) 16:09:55

>>719
*return した値ってオペランドスタックに置かれるんじゃなかったっけ？
ローカル変数領域だったっけか？

723 ：デフォルトの名無しさん：2008/06/13(金) 16:23:43

>>721
java.lang.Doubleにboxingすりゃいいのでは？

>>693みたいな構文糖でいいって場合は配列生成するんだろうし
コストはあんまし重要視してないんじゃないかと。

724 ：デフォルトの名無しさん：2008/06/13(金) 16:31:45

>>693
> Object[] hoge(String c){
> }
> で定義する、でもいいから・・・

これはありえんだろ。型弱すぎw

725 ：デフォルトの名無しさん：2008/06/13(金) 16:35:48

型の話でいうなら変換前の言語の時点での問題だろ。問題にならんと思うが。

726 ：デフォルトの名無しさん：2008/06/13(金) 17:07:14

Object[]よりも無名クラスのオブジェクトの方が向いてるんじゃないの。
ボクシングの問題とか。

727 ：デフォルトの名無しさん：2008/06/13(金) 17:18:16

裏側でクラス作るくらいなら、Object[]でいいと思う
そんな謎のpublicなクラス作られると気持ち悪い。

728 ：デフォルトの名無しさん：2008/06/13(金) 19:54:19

本当に構文糖にできるなら、Object[]の部分は何かで書き換えられると思う。
で、Genericsのようにチェックはコンパイル時ってことでいいんじゃないかな？

729 ：デフォルトの名無しさん：2008/06/13(金) 20:45:07

>>701
そこにタッチ

730 ：デフォルトの名無しさん：2008/06/13(金) 21:07:15

>>712
それは思うなぁー
確か7でStringのswitchができるようになるとかいう噂もあったよな
あれは是非お願いしたい。

731 ：デフォルトの名無しさん：2008/06/13(金) 22:21:24

最近Scala触ってるんだけど、正直Javaの拡張はもういらない気がしてきた。
欲しいなと思ってたものが殆ど揃ってる。

732 ：デフォルトの名無しさん：2008/06/13(金) 22:38:47

JavaよりJVMの方だな、もっとよくなってほしいのは。

733 ：デフォルトの名無しさん：2008/06/14(土) 04:51:09

Java仮想マシンの仮想化機能: Multi-Tasking
http://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は自分の商売に使いたいから提供しないのでしょうけど、
コミュニティが独自に開発しないのは何か事情があるのでしょうか？

734 ：デフォルトの名無しさん：2008/06/14(土) 09:46:14

どの会社も独自に頑張ってるよ。特にJ2ME。

735 ：デフォルトの名無しさん：2008/06/17(火) 01:25:43

MVMはJNIがある限り厳しいという話をこのスレで読んだような・・・

736 ：デフォルトの名無しさん：2008/06/17(火) 03:53:10

>>735
JNI必要な応用ばかりじゃないし、
MVMの基準に合致するJNIの制約を作ることも可能。

737 ：デフォルトの名無しさん：2008/06/17(火) 10:42:44

MVMのJVMとノーマルのJVMを別物と思えばいいような気がするなぁ。
MVMに乗せるアプリは一定基準を守る事って。
Appletだってそうなんだから。

738 ：デフォルトの名無しさん：2008/06/18(水) 10:54:58

タプルは使ったことないからいまいち、どのあたりが有用なのか分からない。
Object[]で簡易的にやりたくないなら、

class タプル内部クラス
String a,b;
でいいんじゃないの？これや[]を超える有用なのところがなにかあるのかな。

739 ：デフォルトの名無しさん：2008/06/18(水) 16:02:15

何で突然タプルの話なの?

740 ：デフォルトの名無しさん：2008/06/18(水) 17:45:39

>>738
端的に2つ言うと、
・別にタプルとしてまとめて扱いたい訳じゃない
・見やすいから使いたい
です。

741 ：デフォルトの名無しさん：2008/06/24(火) 18:54:00

invokedynamicは命令ひとつ追加するだけっていう単純なものじゃないんだな。

742 ：デフォルトの名無しさん：2008/06/26(木) 01:14:36

publicなfieldにするのにObject[]なんかできんし、
ただ組を表現するのにclass定義とか面倒すぎる

743 ：デフォルトの名無しさん：2008/06/26(木) 04:34:06

Map.Entryでえぇやん

744 ：デフォルトの名無しさん：2008/06/27(金) 12:20:21

JDK7 build29
http://download.java.net/jdk7/changes/jdk7-b29.html
http://download.java.net/jdk7/binaries/

745 ：デフォルトの名無しさん：2008/07/04(金) 08:59:42

JDK7 build30
http://download.java.net/jdk7/changes/jdk7-b30.html
http://download.java.net/jdk7/binaries/

746 ：デフォルトの名無しさん：2008/07/09(水) 00:37:03

　　　　＝　＝　＝　寄生虫一家のだんらん　＝　＝　＝

パパ「どうだ～　大画面のプラズマテレビはスゴいだろ～～」
ガキ「スゴいね～　パパ！　これもパパがいつも言ってる愚民からのお金で
　　　買ったの？」
ママ「パパはね、世間がどうなってもたぁ～くさんお金が貰えるし
　　　ボーナスで毎年プラズマテレビと車も買えるんだからぁ～～」
パパ「しかし最近はさぁ～　マイッタよ、職場が禁煙になっちゃってさぁ～
　　　なにしろ30分おきに入り口の外までタバコ吸いにいかなきゃならない
　　　んだからなぁ～、ヘタにそのまま遊びに行くとどこでオンブズマンとか
　　　いう輩が見てるか解らんからなぁ」
ママ「ほんとにあの連中はウジ虫よね！　自分がなれなかったからって
　　　人の幸せをねたんで」
パパ「まぁ、うちはおじいちゃんの代から公務員だからな、チョロい1次試験
　　　さえクリアすれば2次の面接なんて特攻服で行ったって満点合格なんだ
　　　よ、ハ～ッハッハッ！」
ママ「ボクもね、大きくなったら公務員になるのよ、一生遊んで暮らせるん
　　　だから～～」
ガキ「ウン、ママ！　ボクも公務員になるよ。　ところでさぁ、今年もまた
　　　あのタダの保養所に遊びに行くんでしょ？」
ママ「ママねぇ～　あそこ飽きちゃったのよ、休みはいくらでもあるんだから
　　　今年はパリにでも行ってお買い物したいわぁ～～」
パパ「そうだな～～ぁ　カラ出勤と合わせれば1ヶ月は軽いしな
　　　よ～～し、今年の夏はいっちょう行くかぁ～～　ハァ～、ハッハッハ」
ガキ「ワ～イ　ワ～イ」

747 ：デフォルトの名無しさん：2008/07/10(木) 03:18:08

>>693
そこでなぜObject[]をGenericsで表現しないのか

748 ：デフォルトの名無しさん：2008/07/10(木) 03:18:51

>>730
C#と同じノリでいくか。
enumで出来れば十分だろ

749 ：デフォルトの名無しさん：2008/07/10(木) 22:55:31

>>747
複数の返値が型が違う場合を考えて。

750 ：デフォルトの名無しさん：2008/07/10(木) 23:12:29

>>749
それはT=objectで対処可能。

751 ：デフォルトの名無しさん：2008/07/10(木) 23:34:21

>>750
いや、・・・何かGenericsを勘違いしていないか・・・？

752 ：デフォルトの名無しさん：2008/07/11(金) 05:27:30

>>749
戻り値が違う場合？

俺の場合はその戻り値の型を同行する前に
自分で型を作って、二つの型に共通するスーパークラスを
作るにふさわしいかどうかを考えるがな。

そうはいかないときもあるが、そういうときは
根本的に設計上の問題があると考えられる。
デザインパターンを考慮するときはとくに。

753 ：デフォルトの名無しさん：2008/07/20(日) 00:18:11

JDK7 build31
http://download.java.net/jdk7/changes/jdk7-b31.html
http://download.java.net/jdk7/binaries/

754 ：デフォルトの名無しさん：2008/07/21(月) 16:51:54

>>752
(String , Map)
こんな二つの結果が帰ってくるときなら、Superclassも何も無いと思うが・・・

755 ：デフォルトの名無しさん：2008/07/22(火) 21:55:05

TextSS

756 ：デフォルトの名無しさん：2008/07/23(水) 07:28:02

http://mail.openjdk.java.net/pipermail/closures-dev/2008-July/000180.html
> Closures and XML support in Java 7 are unlikely.
だってよ、どーするよ。

757 ：デフォルトの名無しさん：2008/07/23(水) 08:28:01

んん？
unlikelyって・・・見込みがないってこと？

758 ：デフォルトの名無しさん：2008/07/23(水) 09:03:58

実装するのは思いのほか大変だってこと。

759 ：デフォルトの名無しさん：2008/07/23(水) 09:17:18

>>758
実装は http://www.javac.info/ から取ってこれるが。

どっちかっつーと技術的な問題じゃなくて政治的な問題でしょ。
google も http://www.javac.info/google-position.html みたいに及び腰だし。

760 ：デフォルトの名無しさん：2008/07/23(水) 09:48:43

実装という書き方が悪かったね。
今までのJava(Cの延長）からすればたいぶ異質なパラダイムを入れるのに抵抗があるので、思いのほか大変って意味。

761 ：デフォルトの名無しさん：2008/07/23(水) 09:57:18

そういうことかー
英語弱いんで助かりました。

762 ：デフォルトの名無しさん：2008/07/23(水) 09:58:55

>>760
パラダイムとか関係ないでしょ。
Javaにclosure入れるっていう根本方針に反対な人が多数派ってんならともかく。

763 ：デフォルトの名無しさん：2008/07/23(水) 10:00:18

> Java 7 itself is starting to seem unlikely ;-)
orz

764 ：デフォルトの名無しさん：2008/07/23(水) 10:05:11

genericsの時もやたらと遅れたし大規模に言語変更するときはJSRみたいな委員会型の組織だと動き鈍くて大変だよね

765 ：デフォルトの名無しさん：2008/07/23(水) 10:07:56

ぽんぽん尻軽に大規模な言語変更されても困るからしかたない

766 ：デフォルトの名無しさん：2008/07/23(水) 10:14:55

小規模な言語変更だとぽんぽん尻軽にやっちゃうんだけどね。
assert とか勝手に予約語に追加しやがるし。

767 ：デフォルトの名無しさん：2008/07/23(水) 12:43:43

assertが予約語で何か不満でもあるのか？

768 ：デフォルトの名無しさん：2008/07/23(水) 12:55:23

>>767
JUnitで使われてた assert って名前のメソッドが改名させられたのは有名な話。

enum って変数名使ってて泣いた奴も案外多かったりして。

769 ：デフォルトの名無しさん：2008/07/23(水) 13:33:48

それならC#の方が凄いんじゃないの？

770 ：デフォルトの名無しさん：2008/07/23(水) 13:38:08

enumは多かったな

771 ：デフォルトの名無しさん：2008/07/23(水) 13:40:21

>>768
ﾉｼ

772 ：デフォルトの名無しさん：2008/07/23(水) 15:00:16

>>755
http://www.vector.co.jp/vpack/browse/pickup/pw5/pw005236.html

773 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/07/23(水) 19:41:05

>>773
BGGA の初版から 2年、BGGA のver 5出てからもう 1年近くたってるし
未だに時期尚早ってのはなぁ……

Java7 から漏れるそうなのも、jsr166 に closure っつーか
function type 入れたくないよって事なんじゃねーかと邪推したくなる。
doug lea は function type 入れない CICE の提案者の一人だしなぁ。

775 ：デフォルトの名無しさん：2008/07/24(木) 00:08:41

さっさとScalaに移行しようぜ。Javaなんて、使ってられなくなるよ。

776 ：デフォルトの名無しさん：2008/07/24(木) 00:26:39

グルービーはもう廃れちゃったの？

777 ：デフォルトの名無しさん：2008/07/24(木) 00:27:15

あらま。delegate感覚で使えると期待してたのに。
まぁListenerの代替として使いたいって程度だから、
Swing Application Frameworkがあれば十分だけど。

代わりといっちゃなんだがOGNL式の静的チェック機能とか欲しい。

778 ：デフォルトの名無しさん：2008/07/24(木) 05:41:11

なんだこいつ？

779 ：デフォルトの名無しさん：2008/07/24(木) 08:01:33

>>777
その辺は JSR-305 さえ入ってくれれば
@Language("OGNL") とかできるようになるんじゃねーかと思うけど……

780 ：デフォルトの名無しさん：2008/07/27(日) 02:53:17

781 ：デフォルトの名無しさん：2008/07/28(月) 00:10:23

jakartaのなかから標準APIに取り込んで欲しいのは？

782 ：デフォルトの名無しさん：2008/07/28(月) 00:22:28

ない

783 ：デフォルトの名無しさん：2008/07/28(月) 00:28:42

俺もないなあ
標準APIは太りすぎだろ

784 ：デフォルトの名無しさん：2008/07/29(火) 16:07:43

EEやSEに突っ込んだら勝ちって競争になりつつあるからね。
土方プログラマ方面では標準化して統一してほしいだろうし。

785 ：デフォルトの名無しさん：2008/07/29(火) 16:24:35

いくら標準化しても、おまえじゃ使えないだろうな。おまえが使えるようになった頃には既に誰も使ってないだろうしw

786 ：デフォルトの名無しさん：2008/07/29(火) 17:15:22

jakarta、generics対応してないの多いからな

JDK1.3くらいのときはありがたかったものも今では必要ないとかかなりあるからね

787 ：デフォルトの名無しさん：2008/07/29(火) 17:35:02

正直、言語面の変化しか注目してない。
後は自分の使いたいクラスライブラリ使う。

788 ：デフォルトの名無しさん：2008/07/29(火) 17:44:27

JSR-203 の試験版。
http://download.java.net/jdk7/jsr203/binaries

しっかし、これ
pfav.setOwner(fs.getUserPrincipalLookupService().lookupPrincipalByName("hoge"));
とか横に長すぎなんですが……
commons-nio が必要になる予感

789 ：デフォルトの名無しさん：2008/07/29(火) 17:49:12

メソッド名長くしすぎると、
Jakarta Commons VFSに負けちゃうかも…

>>774
CICEはクラス中心的でJavaっぽくていいんだけど、
これだけじゃ物足りないね。

790 ：デフォルトの名無しさん：2008/07/29(火) 17:52:12

それからDoug Lea先生は、JSR-166との絡みで、
control abstractionにまいっちゃってる可能性が…
そうするとBGGA, FCMに吸い寄せられるような

791 ：デフォルトの名無しさん：2008/07/29(火) 19:23:49

>>788
生APIってのはそんなもん
だからみんなファサード大量に容易するわけだ

生APIの場合は出来ないことが存在することがまずいわけで
多少のインターフェースの悪さは無視するのが普通かと

792 ：デフォルトの名無しさん：2008/07/29(火) 19:50:04

>>791
>>788 の例は、出来る出来ないの話じゃなくて、どっちかっつーとクラス構造(?)の話かな。

UserPrincipal extends java.security.Principal 使う必要があるんか？って話。
setOwner(String) でいいじゃんって思うんだけど。String じゃダメな理由あるんかな？

793 ：デフォルトの名無しさん：2008/07/29(火) 22:05:32

極端に言えば、BGGA以外は匿名クラスとあまり差はないし、ならクロージャいらないとの議論になりかねない。
BGGA自体も、関数言語指向の方向性は自然な姿だけど、controlのあれはビックリしたけどね。
なんだかんだ言ってサポートされるからブログとか追いかけて気にし過ぎだなｗ

794 ：デフォルトの名無しさん：2008/07/30(水) 00:15:33

>>793
ネストしたときのわけわからなさは異常

1つのメソッドのみのインターフェースを書くのがだるい人向けかな
業務系だと型そのものが大事ではなくてインターフェース名そのものが大事だから
あんまり使われないと思う

795 ：デフォルトの名無しさん：2008/07/30(水) 00:37:34

総称型はコンパイラ時の型安全のつもりだろうけど、インターフェイスの引数で使うとまったく違った使い方ができるし、
クロージャも同じように使ってるうちに全く想定外の使い方がでてくるんじゃないの。

interface Inte <T extends java.lang.Number>
{
int compareTo(T obj);
}

Inte<BigDecimal>だとobj.subtract(this)とかできる。

796 ：デフォルトの名無しさん：2008/07/30(水) 01:22:10

>>795
日本語でもうちょっとわかりやすく

797 ：デフォルトの名無しさん：2008/07/30(水) 01:33:57

言ってることはわかる気がするが
それなんか意味あるの？

798 ：デフォルトの名無しさん：2008/07/30(水) 02:18:49

>>784
> 土方プログラマ
がエアプログラマにみえたので眼鏡を新調してくる。

799 ：デフォルトの名無しさん：2008/07/30(水) 05:00:44

>>798
おまえのそのメガネは高く売れる。

800 ：デフォルトの名無しさん：2008/07/30(水) 05:12:58

>エアプログラマにみえた

正解です

801 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/07/30(水) 12:00:59

こんなん見つけた。
http://blogs.sun.com/abuckley/en_US/date/20080728

module を言語全体のキーワードでなく文脈依存のローカルキーワードにしたいんだけど、例えば
　class classname { module classname(){ throw new Error(); } }
って宣言があった場合、module型を返すメソッドなのか
module privateなコンストラクタなのか判別付かなくて悩ましいというお話。

互換性だけを考えると module型を返すメソッドにするべきなんだろうけど……

803 ：デフォルトの名無しさん：2008/07/30(水) 14:08:05

>>796
おまえの知能を疑うが、どこを日本語にして分かりやすくして欲しいんだ？

804 ：デフォルトの名無しさん：2008/07/30(水) 15:34:07

>>803

>>795のどこが不思議な使い方なんだ?

805 ：デフォルトの名無しさん：2008/07/30(水) 15:52:28

つ >>795にとって不思議

806 ：デフォルトの名無しさん：2008/07/30(水) 18:02:10

>>804-805
お前らの頭の中は不思議でいっぱい

807 ：デフォルトの名無しさん：2008/07/30(水) 18:42:40

>>768
あれは面倒くさかった。
ぜんぶassert()メソッドをassertEquals()やassertNotTrue
とかに変更する羽目になった

808 ：デフォルトの名無しさん：2008/07/30(水) 18:44:49

>>781
Log4jかな。あれを標準化したロギングAPIと統合して欲しい。
ライブラリ依存関係で混乱するから。

Commons Math、Commons Collections、Commons Configurations
も標準APIにいれて欲しい

809 ：デフォルトの名無しさん：2008/07/30(水) 18:48:12

>>786
CollectionsのGenerics対応はまだまだ遅いよな。
別ライブラリとしてGenerics対応されたやつがあるだけで
まだまだ時間かかりすぎる。

810 ：デフォルトの名無しさん：2008/07/30(水) 18:53:19

マ版でやってくれないか？

811 ：デフォルトの名無しさん：2008/07/30(水) 19:03:07

この話題はマ板じゃねぇだろ

812 ：デフォルトの名無しさん：2008/07/30(水) 19:44:09

>>802
単純型名で module型が使える場合は module型を返すメソッド、
そうでなければ module privateなコンストラクタってのはダメなんかね？

module型使ってる場合は module privateなコンストラクタを一切使えなくなるけど、
それはmodule privateな静的ファクトリメソッド使うなりして我慢してもらう方向で。

813 ：デフォルトの名無しさん：2008/07/30(水) 20:52:30

>>811
いや。十分にマ版ネタだと思うが。

814 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/07/30(水) 21:05:42

>>813
キーワードが増えてこまったこととか、CollectionsのGenerics対応とか、技術ネタだろ。マ板にもっていく必要性がわかんない。

816 ：デフォルトの名無しさん：2008/07/30(水) 21:51:13

技術ネタなんじゃなくて、おまえの愚痴でしかないようだが？

817 ：デフォルトの名無しさん：2008/07/30(水) 21:59:29

ネタとして次世代Javaではなさそうだが。

818 ：デフォルトの名無しさん：2008/07/30(水) 22:02:04

>>816
まぁ、落ち着けよ。
宿題やったか？早いうちに終わらせとけよ。

819 ：デフォルトの名無しさん：2008/07/30(水) 22:15:07

>>814
module で export package 指定できりゃそれで良いんじゃ？

820 ：デフォルトの名無しさん：2008/07/31(木) 00:52:21

>>818
早く死ねよ

821 ：デフォルトの名無しさん：2008/07/31(木) 01:48:01

>>819
それはC/C++のヘッダファイルと同じ運命を辿らないか？
できればimport宣言はそのクラス内ですませたい

822 ：デフォルトの名無しさん：2008/07/31(木) 03:08:13

>>818
ITドカタは来えろ

823 ：デフォルトの名無しさん：2008/07/31(木) 08:22:28

>>821
> それはC/C++のヘッダファイルと同じ運命を辿らないか？
ってどーゆー事？

「export うんたら」はモジュール外から使えるクラス「うんたら」だけに制限する。
>>814 みたいな事は OSGi の Export-Package 使えばできるんじゃね？って思うんだが。
JSR-277 はそこんとこはクラス単位みたいだけど
それをパッケージ単位でもできるようにすれば良いだけのよーな。

824 ：デフォルトの名無しさん：2008/07/31(木) 10:03:56

>>801
Attributes.getBasicFileAttributes(path, true).isDirectory() までは短くなるな。

十分長いよーな気もするけど。
new File(path.toUri()).isDirectory() に比べても、まだ長いし。

825 ：デフォルトの名無しさん：2008/07/31(木) 10:12:33

>>812
そんな事するぐらいなら module を言語全体に影響するキーワードにした方がすっきりせんか？

変数名とかフィールド名にmoduleって名前使ってる人には泣いてもらう事になるけど。

826 ：デフォルトの名無しさん：2008/07/31(木) 11:51:29

SunにはJavaのコードからexeバイナリを生成するコンパイラの開発をしようという計画は無いんですかね
VM作ってるぐらいだからやる気になればそう難しくなさそうですが
本末転倒かな便利だと思うけど

827 ：デフォルトの名無しさん：2008/07/31(木) 11:59:58

>>826
スレ違いのレベルも下がったな。夏休みか。gcjでも食ってろ蛸。

828 ：デフォルトの名無しさん：2008/07/31(木) 12:13:47

>>826
スレ違いのレベルも下がったな。夏休みか。Visual J#でも食ってろ蛸。

829 ：デフォルトの名無しさん：2008/07/31(木) 12:47:13

粘着はそろそろ消えてくれないか

830 ：デフォルトの名無しさん：2008/07/31(木) 12:49:15

>>825
影響範囲がでかすぎる。
assertのときほどJavaはマイナーではないし、enumほどみんなに使われるわけでもない。
ほとんどの人が直接使わないのにキーワードにされたら、そりゃ怒るだろね。

831 ：デフォルトの名無しさん：2008/07/31(木) 13:05:12

>>830
moduleって名前使ってない人は怒らないから大丈夫。
それに列挙型よりはモジュール機能の方が使用頻度高いと思うが。

言語仕様汚れる方が将来の言語拡張の妨げになるから嫌って人も多いし。

832 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/07/31(木) 13:26:23

>>827
使いものになんねーだろあれ

834 ：デフォルトの名無しさん：2008/07/31(木) 14:11:32

gcjはclasspath使って書き換えるからそれが完了すれば5.0までいけるんだけどな。

835 ：デフォルトの名無しさん：2008/07/31(木) 14:52:33

もうウザイし、誰か相手してやれよ。

836 ：デフォルトの名無しさん：2008/07/31(木) 15:58:31

>>831
言ってることが良く分からないんだけど、どの言語仕様が汚くなるの？

837 ：デフォルトの名無しさん：2008/07/31(木) 16:56:07

>>836
全体にキーワード適用した方が言語仕様が単純に保てて汚れずに済むって話。

>>812みたいな小細工が汚れそのもの。

838 ：デフォルトの名無しさん：2008/07/31(木) 16:57:51

>>831
今後の言語拡張だけじゃなくてコンパイラの単純さ健全さバグの少なさにも影響してくるし。

839 ：デフォルトの名無しさん：2008/07/31(木) 19:27:08

はあ？

840 ：デフォルトの名無しさん：2008/07/31(木) 19:48:45

>>837-838
抽象的で分からないんだけど、もうちょっと具体的に技術的な話は出来ないの？

841 ：デフォルトの名無しさん：2008/07/31(木) 22:33:06

>>840
お前、このスレ来るのまだ早いよ。

842 ：デフォルトの名無しさん：2008/07/31(木) 22:40:07

↑頭おかしいだろ？早く病院行ったほうがいいぞ

843 ：デフォルトの名無しさん：2008/07/31(木) 23:34:18

>>840
言語仕様に追加する場合考えてみ？

全体キーワードなら 3.9 Keywords に module 加えればいいだけ。
>>812 をやろうとすると、大量に書き換えが必要になる。

844 ：デフォルトの名無しさん：2008/08/02(土) 17:57:54

>>843
もう全体キーワードの追加は認められないだろね。
moduleなんてパッケージ名はどこにでもありそうだし。
言語処理側ががんばればいいのなら、それでやるべきだと思う。

845 ：デフォルトの名無しさん：2008/08/02(土) 19:36:50

いっそのことmojuleとかにしちゃえばいいのに

846 ：デフォルトの名無しさん：2008/08/02(土) 19:53:09

ところで、module って本当に jdk7に間に合うのか？
OSGi との互換性とか整合性とかどーすんだろね？

なんつーか >>763 の予感が……

847 ：デフォルトの名無しさん：2008/08/02(土) 22:25:45

>>845
それなんてCloneable？

848 ：デフォルトの名無しさん：2008/08/02(土) 23:17:36

そろそろC＃が巻き返してくるんじゃないのか？

849 ：デフォルトの名無しさん：2008/08/03(日) 01:27:02

意味がわからん

850 ：デフォルトの名無しさん：2008/08/03(日) 01:35:26

確かにC#の方が儲かる罠

851 ：デフォルトの名無しさん：2008/08/03(日) 02:35:05

Scalaでえぇよ

852 ：デフォルトの名無しさん：2008/08/03(日) 03:07:57

>>850-851
スレ違い

853 ：デフォルトの名無しさん：2008/08/03(日) 03:25:49

>>848-849
スレ違い

854 ：デフォルトの名無しさん：2008/08/03(日) 04:14:44

>852-853
スレ違い

855 ：デフォルトの名無しさん：2008/08/03(日) 05:46:06

せっかく期待したのにお流れになった機能とかは、MSのやつなら使えるからジャヴァには期待してない。けっきょくジャヴァ使っててもWindowｓしか使わないしｗ

856 ：デフォルトの名無しさん：2008/08/03(日) 07:20:31

ジャヴァとか馬鹿じゃね？

857 ：デフォルトの名無しさん：2008/08/03(日) 07:28:50

確かに今はバカかも試練が、7が出ればそうも言ってられなくなる。
そう思いたい。

858 ：デフォルトの名無しさん：2008/08/03(日) 08:08:30

age厨は意味取り違えるのが好きらしい

859 ：デフォルトの名無しさん：2008/08/03(日) 11:18:41

そのようだ
夏だからしょうがないか

860 ：デフォルトの名無しさん：2008/08/03(日) 14:00:57

どこも夏だな

861 ：デフォルトの名無しさん：2008/08/03(日) 14:23:47

ジャヴァジャヴァ

862 ：デフォルトの名無しさん：2008/08/03(日) 16:32:20

kusosure

863 ：デフォルトの名無しさん：2008/08/03(日) 17:20:09

moduleは導入されるけど、closureは無理だろうな。
英語のページだと悲観的見解が多い。
やっぱりいつまでも指をくわえて待ってないで、C#とか既にあるのを使えばいいんじゃないか。C#は使ったことないけど・・

864 ：デフォルトの名無しさん：2008/08/03(日) 17:30:44

> 英語のページだと悲観的見解が多い。
どこ？

865 ：デフォルトの名無しさん：2008/08/03(日) 17:33:42

そーいや closureのプロトタイプが nonlocal return サポートしたってさ。
break と continue は、また今度らしい。

http://mail.openjdk.java.net/pipermail/closures-dev/2008-August/000190.html

866 ：デフォルトの名無しさん：2008/08/03(日) 17:47:20

>>865
nonlocal return すると例外吐いてコンパイラ落ちるんだが。

>>788 の NIO2のEA版じゃなくて、正規のjdk1.7使わんと駄目なんだろうか？

867 ：デフォルトの名無しさん：2008/08/05(火) 10:14:55

break と continue も来たってさ。
これで今のところ予定してる機能はコンプリートしたらしい。
http://mail.openjdk.java.net/pipermail/closures-dev/2008-August/000193.html

>>866
今回のは >>788 の NIO2のEA版でも大丈夫だったぞ。

868 ：デフォルトの名無しさん：2008/08/05(火) 12:39:28

XMLリテラルって何でなくなっちゃったの？

869 ：デフォルトの名無しさん：2008/08/05(火) 16:05:52

>>867
www.javac.info つながらなくね？

870 ：デフォルトの名無しさん：2008/08/05(火) 19:52:57

7というのが、Windows7 か Java7かは謎だな。

871 ：デフォルトの名無しさん：2008/08/08(金) 03:53:55

>>868
おまえが馬鹿だからじゃね？

872 ：デフォルトの名無しさん：2008/08/09(土) 05:22:27

ゴチャゴチャしているようだけど、使ってみるとC#結構いいよ。癖になりそう

873 ：デフォルトの名無しさん：2008/08/09(土) 10:02:24

夏だなぁ。

874 ：デフォルトの名無しさん：2008/08/09(土) 10:29:07

>>872
スレ違いなんだよアホ

875 ：デフォルトの名無しさん：2008/08/09(土) 12:33:00

やっぱりscalarじゃね？

876 ：デフォルトの名無しさん：2008/08/09(土) 13:04:31

package単位でFacadeパターンを実現する手法ができるとは限らないのか

877 ：デフォルトの名無しさん：2008/08/10(日) 00:24:57

>>874
C++すらも使いこなせないんですか？

878 ：デフォルトの名無しさん：2008/08/10(日) 02:00:13

>>877
またお前か・・・

879 ：デフォルトの名無しさん：2008/08/10(日) 02:15:14

>>878
だれのことだよｗ

880 ：デフォルトの名無しさん：2008/08/10(日) 02:16:53

お前だよw

881 ：デフォルトの名無しさん：2008/08/10(日) 02:45:48

C++ぐらいは使えこなせるけど何か？

882 ：デフォルトの名無しさん：2008/08/10(日) 03:28:36

>>878-880
こういう奴はよく沸いてくるんだけど、どこかの糞溜めに消えてくれないか？

883 ：デフォルトの名無しさん：2008/08/10(日) 09:17:41

夏だな・・・

884 ：デフォルトの名無しさん：2008/08/10(日) 09:20:26

もとから糞の奴はどこに行けばいいんだよ！

885 ：デフォルトの名無しさん：2008/08/10(日) 13:03:51

Java Module SystemはRPMと同等だとみなしてもいいよね？

886 ：デフォルトの名無しさん：2008/08/10(日) 14:06:44

かってにみなせば？

887 ：デフォルトの名無しさん：2008/08/10(日) 16:34:31

>>885
レイヤーからして違う。

888 ：デフォルトの名無しさん：2008/08/10(日) 17:17:13

JavaでもC++でも、どうせ俺たちはIT土方じゃね？

889 ：デフォルトの名無しさん：2008/08/10(日) 21:55:32

もういいよ。土方がそんなに嫌なのか？
経営者以外は土方みたいなもんだ。
自分のやることにちったー誇りもてよ？

890 ：デフォルトの名無しさん：2008/08/10(日) 23:47:00

マ板で話題にすることだね。
そっちでならスレを指定すれば
話に加わってもいいよ。
ここではマ板な話はスルー。

>>865
RPMよりyumのように扱えれば便利だよね。
それもMavenですでに実現しているかな？

891 ：デフォルトの名無しさん：2008/08/11(月) 01:18:14

ちぇ、ツマンネー奴らだな。
経営者なんて、外じゃペコペコ頭下げて、無理な要求持ってきて迷惑なだけじゃん。
人として感情をもってないペコちゃん人形と同じだな。

892 ：デフォルトの名無しさん：2008/08/11(月) 02:37:05

>>891

これは・・・

893 ：デフォルトの名無しさん：2008/08/11(月) 04:01:45

マ版の奴らと同じように本当のところは経営者もしんどいんですよ・・・

894 ：デフォルトの名無しさん：2008/08/11(月) 04:24:58

夏真っ盛りだな・・・眠すぎる

895 ：デフォルトの名無しさん：2008/08/11(月) 07:49:00

どっちにせよマ板の話題

丁度いいスレがあったから紹介しておくよ

ITﾍﾞﾝﾁｬｰ経営者だがそろそろ畳もうと思う
http://pc11.2ch.net/test/read.cgi/prog/1198225909/

896 ：デフォルトの名無しさん：2008/08/11(月) 09:33:15

経営者は常に最新のものに敏感でいなければならないため、次世代スレに興味あるんですが何か問題でも？

897 ：デフォルトの名無しさん：2008/08/11(月) 10:40:01

そのスレ違いの発言が問題。

898 ：デフォルトの名無しさん：2008/08/11(月) 12:04:24

くそすれ

899 ：デフォルトの名無しさん：2008/08/11(月) 12:43:35

またお前なのかよ

900 ：デフォルトの名無しさん：2008/08/12(火) 00:53:15

それで、クロージャ実装の使い心地はどうよ？

901 ：デフォルトの名無しさん：2008/08/15(金) 02:59:03

クロージャさえあればcatch節でclose()忘れを防ぐことができる
ギャグが現実化すればのう

902 ：デフォルトの名無しさん：2008/08/17(日) 11:48:43

JDK7 build33
http://download.java.net/jdk7/changes/jdk7-b33.html
http://download.java.net/jdk7/binaries/

903 ：デフォルトの名無しさん：2008/08/28(木) 22:27:20

クロージャどう見ても糞だろ？
なんだよあの関数型w
宣言とか仮引数にいちいちあんなの書いてられるか
インタフェースへのキャストも糞仕様としか思えない
メソッド定義が一つの時だけできるとかまともな設計センスじゃないだろ

904 ：デフォルトの名無しさん：2008/08/28(木) 22:32:38

メソッド定義が一つの時だけできるとか、嘘つくなよ
まずは仕様をちゃんと読め。それから。

905 ：デフォルトの名無しさん：2008/08/28(木) 22:50:09

>>904
ちょっと誤解してたわ
引数が同じものがあったらダメってことか
どっちにしても分かりにくい上にわざわざこんなことしてまで使いたくないな

906 ：デフォルトの名無しさん：2008/08/28(木) 22:55:18

Javaはもうこのままでいいよ。
他の言語のプラットフォームとしてがんばってくれれば。
俺はScalaに逝く。

907 ：デフォルトの名無しさん：2008/08/28(木) 22:59:08

Javaはまだカオスを十分に溜め込んだとはいえないからなぁ
言語仕様そのものはシンプルだし、GenericsやAnnotationの類が
もう２，３種増えないとリファクタリングの効果が薄い気がする。

908 ：デフォルトの名無しさん：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);

にできなかったのか？

909 ：デフォルトの名無しさん：2008/08/28(木) 23:04:55

それありだわー
単純でいいなぁ

910 ：デフォルトの名無しさん：2008/08/28(木) 23:13:59

それ、typedefした関数ポインタと同じじゃないの？
とっくに議論尽くされて今の仕様まで来たんだけ、全然知らないくせに横から口出すなよ。
おまえはscla使ってれ。たいした差はないと思うけどなｗ

911 ：デフォルトの名無しさん：2008/08/28(木) 23:16:57

function F(int i, int s) { x +y }

F f = new F();
f(10, 20);

これなんか、クラス宣言をちょっとだけ省略した普通の関数（クラス）の宣言じゃんｗ
アノニクラスと一緒にしてるみたいだし、おまえアホだろ？

912 ：デフォルトの名無しさん：2008/08/28(木) 23:24:53

いまのインタフェース下のキャストより10倍はましだが？

interface 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);

書いててばかばかしいと思わん？

913 ：デフォルトの名無しさん：2008/08/28(木) 23:37:23

どこが馬鹿馬鹿しいのか分かるようにちゃんと指摘できないのは、バカｗ

914 ：デフォルトの名無しさん：2008/08/28(木) 23:38:33

>>912
関数が多言語使ってるくせに、数学のことまるっきり分かってないようだなｗ
おまえばかだろ？

915 ：デフォルトの名無しさん：2008/08/28(木) 23:49:47

interface 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); //わざわざinvoke()を特別扱い。インタフェースには定義ないし、きもいね

とか

{ int, int => int } f = { int x, int y => x + y }; //{ int, int => int }って、こんなの持ち回るんかい！
f(.invoke(10, 100);

もうねinvokeの特別扱いとかいろいろ導入してんだよ
こんなことやるくらいならもっといろいろできただろ

>>914
数学（笑）
頭いいならさ説明してみろよ

916 ：デフォルトの名無しさん：2008/08/29(金) 00:44:01

久しぶりに誤変換で笑った。
関数型言語を使ってれば数学チックな思考を出来るようになっていてもいいんじゃないの？

917 ：デフォルトの名無しさん：2008/08/29(金) 00:45:29

>>915
君が糞だって事はよーく分かったからｗｗ

918 ：デフォルトの名無しさん：2008/08/29(金) 00:47:16

また糞だめから出てきたのか。

919 ：デフォルトの名無しさん：2008/08/29(金) 01:00:25

糞は糞らしくVBでもやってろｗ

920 ：デフォルトの名無しさん：2008/08/29(金) 01:09:46

VBは早くからUnicodeに対応したユーザフレンドリな言語だと思うが。
ある意味Javaの先輩といってもいいくらいの。

921 ：デフォルトの名無しさん：2008/08/29(金) 01:27:20

javaはこのまま暗黒面に落ちていくと思う。（言語仕様が）

922 ：デフォルトの名無しさん：2008/08/29(金) 01:28:10

もうJAVAはだめぽ（。。

923 ：デフォルトの名無しさん：2008/08/29(金) 02:27:58

ライブラリの仕様はJCPのようなプロセスを経るのもいいのだろうけど、
言語仕様はSUNがびしっと決めてしまったほうがましな気がするな。
船頭多くしてなんとやらだよ、まったく。

924 ：デフォルトの名無しさん：2008/08/29(金) 02:30:48

>>908
Javaはtypedefはやらない流儀。別名を導入しない。
function F(int i, int s);は別名導入しているに等しい。

925 ：デフォルトの名無しさん：2008/08/29(金) 02:39:15

いっそ、functionよりdelegate void F(int i, int s)がよくないかな

926 ：デフォルトの名無しさん：2008/08/29(金) 02:47:55

いや => が混乱の元。

{int o => o<=1 && o>=-1} なんか笑われてるようにしか見えないじゃんか。

もうJAVA終わったorz

927 ：デフォルトの名無しさん：2008/08/29(金) 03:04:36

closureってまだ入らなそうな感じなんじゃないの?
個人的にはfunction typeの構文がかなり可読性を下げる気がするのでやめて欲しい。
型名書いているのかブロック書いているのか分からなくなる。

928 ：デフォルトの名無しさん：2008/08/29(金) 03:08:36

=> は伝統だろ

929 ：デフォルトの名無しさん：2008/08/29(金) 03:22:29

>>927
糞だからな

930 ：デフォルトの名無しさん：2008/08/29(金) 03:54:34

>>927
お前の可読性の好みなど聞いてない

931 ：デフォルトの名無しさん：2008/08/29(金) 06:23:44

ジャバのスレじゃないのか！ジャバが終わったとかC#にしろとか何を愚かなこといってるんだぁ

932 ：デフォルトの名無しさん：2008/08/29(金) 10:29:24

カタカナで書かれると、風呂釜洗い出しそう

933 ：デフォルトの名無しさん：2008/08/29(金) 16:01:03

ジャバはジャバだろ！コーヒーじゃないんだぞ！

934 ：デフォルトの名無しさん：2008/08/29(金) 17:19:05

カバオくんお風呂に入ってハァビバノノ
s/JAVA/KABA/ だめだこりゃ

935 ：デフォルトの名無しさん：2008/08/29(金) 17:19:22

もうVBとVBAだけあれば、俺は幸せ！

936 ：デフォルトの名無しさん：2008/08/29(金) 19:42:34

>>924
おまえはクロージャのインタフェースへのキャスト仕様理解してから話せ

937 ：デフォルトの名無しさん：2008/08/29(金) 20:07:04

>>934
KABAはPrologだけど、知らないんだろうな・・・

938 ：デフォルトの名無しさん：2008/08/29(金) 20:43:30

じゃあ

未だにIISオンリーで糞重C#とか、化石のVBとか、MatzクンのオナニーRubyとか？

ねーよｗｗありえねーわｗｗｗｗｗｗ

939 ：デフォルトの名無しさん：2008/08/29(金) 22:12:36

お前アホだなぁｗｗ
CやVBは化石なんじゃなくて歴史があるってもんよ。
C#なんか常々進化してんじゃん。

それを言うならjavaの方がもう化石なんじゃねーの？

940 ：デフォルトの名無しさん：2008/08/29(金) 23:10:22

まるでJavaが進化してないみたいな言い方だな
2年に一度は大きいアップデートがある（EEも含めると毎年ある）環境だというのに

昔の言語と違って今の言語はどれも大幅な更新が入るのは当たり前だぞ

941 ：デフォルトの名無しさん：2008/08/29(金) 23:15:42

低レベルな言語比較なら他スレでどうぞ

942 ：デフォルトの名無しさん：2008/08/29(金) 23:19:28

and, because of you, you should accept the closure proposal for next generation.

943 ：デフォルトの名無しさん：2008/08/30(土) 06:01:48

何この糞スレ？

944 ：デフォルトの名無しさん：2008/08/30(土) 06:40:38

もうJavaなんてやめちまえ！

945 ：デフォルトの名無しさん：2008/08/30(土) 11:32:40

他の言語のスレで叩かれた厨が流入してるんだろう
しばらくの辛抱だw

946 ：デフォルトの名無しさん：2008/08/30(土) 23:25:58

でもrubyは宗教だろ

947 ：デフォルトの名無しさん：2008/08/31(日) 02:10:45

perlは宗教じゃなきゃ何よ？

948 ：デフォルトの名無しさん：2008/08/31(日) 02:39:31

プログラミング言語

949 ：デフォルトの名無しさん：2008/08/31(日) 08:45:43

驚くほど糞スレ
こんなスレに興味を抱いた俺が馬鹿だったわ

950 ：デフォルトの名無しさん：2008/08/31(日) 09:00:31

続きはマ板でね

951 ：デフォルトの名無しさん：2008/08/31(日) 10:30:15

>>949
おまえのような糞に言われたくない罠

952 ：デフォルトの名無しさん：2008/09/01(月) 12:25:27

>>951
その辺の返し方がクソスレｗｗ

953 ：デフォルトの名無しさん：2008/09/01(月) 17:29:50

typedefもどきはやめてくれ
ソースコードが読みにくくなるんだよ

954 ：デフォルトの名無しさん：2008/09/01(月) 20:08:09

>>952
糞は無理して発言しなくていいよ。それよか、海外でもいいから、ねたブログとかないの？

955 ：デフォルトの名無しさん：2008/09/01(月) 21:09:19

今のクロージャの仕様はtypedefよりひどいじゃねーかww

interface 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);

なんだよこれ

956 ：デフォルトの名無しさん：2008/09/01(月) 21:40:54

どこかどう酷いのか書いてない用だけど…
おまえ、あたま大丈夫？

957 ：デフォルトの名無しさん：2008/09/01(月) 23:14:13

>>955
これってメソッドが2つあるからコンパイルエラーでは?
なんか問題あるの?

958 ：デフォルトの名無しさん：2008/09/01(月) 23:37:41

>>957
ところが仕様ではこれがOKなのさ
驚きだろ？

959 ：デフォルトの名無しさん：2008/09/02(火) 03:31:21

これ自体は、イヤな動きだけども、これはどのくらいの頻度でありうるものなのかな
そして、どのくらいの頻度で、問題のある動きになるのかな？

メリットはかなり大きいと思うが、割りにあうのかないのか

960 ：デフォルトの名無しさん：2008/09/02(火) 03:33:35

>>955
それならもうC#しかないな。C#でもDでもいいから、一緒にやらないか？

961 ：デフォルトの名無しさん：2008/09/02(火) 03:42:20

Scalaでいいよ！

962 ：デフォルトの名無しさん：2008/09/02(火) 03:52:42

scalaだけど少し調べてみたけど数年後には来そうだね。
でもグルービーと比べるとイマイチ違いがないんだよね（言語機能じゃなくて）。
グルービーはJSRで仕様堅めに入ってるから先が見込めるけど、scalaは（言語機能じゃなくて）普及の兆しを感じないな。

個人的にはjdk1.6で既にサポートされてるrhinoでいいんじゃないかと思う。

963 ：デフォルトの名無しさん：2008/09/02(火) 04:00:21

静的型でクラスファイルができるのと、スクリプトと、違いがないってのか。
しかもrhinoでいいんじゃないかとかいう。

その言語で作ったクラスをJavaで自由に扱えるかどうかも、でかいとおもうよ。

964 ：デフォルトの名無しさん：2008/09/02(火) 04:04:13

↑全く意味不明なので、書き直してもらえませんか？

965 ：デフォルトの名無しさん：2008/09/02(火) 04:05:43

rhinoやgroovyじゃ、Java言語の代わりにはなれません。

966 ：デフォルトの名無しさん：2008/09/02(火) 06:29:38

スクリプトサポートの目的はJavaの代わりになるかでなくて、Javaでは難しいところやかゆいところに手が届くって意味じゃないの？

967 ：デフォルトの名無しさん：2008/09/02(火) 06:34:55

個人レベルで使うなら何だっていいが、企業向け開発だとなぁ
言語仕様も大事だが、大手のサポートやツールの有無
つまり周辺環境がないとどうしようもない
今んところ実質的な代替はC#にしかできないでしょ
あとはRubyがちょっと流行ったくらい
JavaがgdgdになるならScalaもありかもしんないけど
企業向けに立ち上がるにはよほど運がないと無理でしょ

968 ：デフォルトの名無しさん：2008/09/02(火) 06:39:28

java langやjvmがサポートするのはフレームワークだと思うんだが、なんか外してないか？
まあ、このスレはこの程度かｗ

969 ：デフォルトの名無しさん：2008/09/02(火) 06:42:36

>>966
Scalaはスクリプトサポートではなく、Java言語の代替として使うことを考えられてる。
だから静的コンパイルされてクラスファイルを生成して動かす。
そうすると、Javaと同等かそれ以上の速さで動く。
クラスファイルだから、Javaからも比較的自由に使える。つまり特別な仕組みを使わなくてもServletやJPAのクラスが作れるということ。
部分的な適用がやりやすくなる。
で、今は、Javaの言語仕様拡張よりScalaじゃねぇの？って文脈。Javaの代わりになるかという話。

>>967
企業向けのエンドプログラマはJava1.4で充分でしょ。

970 ：デフォルトの名無しさん：2008/09/02(火) 06:43:38

言語オタクのおもちゃならScalaで十分
Javaになんでもかんでも詰め込んで欲しいとは思わん

971 ：デフォルトの名無しさん：2008/09/02(火) 07:14:40

>>969みたいな
こういう俺様俺様ってのはどこにでもいるよなｗｗC++なんかこんな奴らの固まりだしｗｗ

972 ：デフォルトの名無しさん：2008/09/02(火) 07:17:44

スカラもグルービも、ジャヴァも、クラスファイルを作ってJVMプラットフォームで動くんじゃなかったの？（.Netみたいに）

973 ：デフォルトの名無しさん：2008/09/02(火) 08:04:16

企業向けだって1.4じゃつらすぎる。5つかっててｵﾓﾀ。

974 ：デフォルトの名無しさん：2008/09/02(火) 08:19:55

rhinoもバイトコードコンパイラあるんだが

975 ：デフォルトの名無しさん：2008/09/02(火) 10:45:01

ジャヴァジャヴァ

976 ：デフォルトの名無しさん：2008/09/02(火) 17:12:24

>>958
v0.5って仕様にはclosure conversionはsingle methodを持つもの、
って書いてあるのでそのケースはエラーになると思ったんだけど、どっか他に仕様がある?
呼ばれるメソッドが不定に見えるのでエラーにするのが普通だと思うんだが。

あと最後のinvokeはFがinvoke持ってないからエラーになるような。invokeに関しては、function typeがinvokeを持つinterfaceとして扱われるのでは。

977 ：デフォルトの名無しさん：2008/09/02(火) 20:35:43

Tグループの会社を何件か見たが、どこもJava1.3が入ってたりして焦った。
定期的にアップグレードする計画を立てるのもシステム課の重要な仕事だな。

978 ：デフォルトの名無しさん：2008/09/02(火) 20:51:02

いろいろ動かなくなるからアップグレードしちゃだめだよ

979 ：デフォルトの名無しさん：2008/09/02(火) 21:15:02

>>976
それが普通だよな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

980 ：デフォルトの名無しさん：2008/09/02(火) 21:18:48

>>978
部署に一台、事務処理専用マシンを作っていくのは基本だろ？

981 ：　：2008/09/02(火) 21:27:40

>>979　それが通るなら、逆にこれも通るのかな？

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);

982 ：デフォルトの名無しさん：2008/09/02(火) 21:50:23

>>981
それは無理だよ
どこにもクロージャ使ってないでそ

983 ：デフォルトの名無しさん：2008/09/02(火) 22:31:58

こいつは、メソッドレファレンスMyClass#meth()のこといってんじゃないの？

984 ：デフォルトの名無しさん：2008/09/02(火) 22:56:47

なんだそりゃw

985 ：デフォルトの名無しさん：2008/09/02(火) 23:09:29

Java 7の目玉機能は、クロージャだけなんですか？

986 ：デフォルトの名無しさん：2008/09/02(火) 23:18:10

モジュール？

987 ：デフォルトの名無しさん：2008/09/02(火) 23:24:08

>>979
その仕様はどこに書いてあるん?
なんでその例外的ルールがあるのかわらない。

それから、
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呼ぶのはそんなに無いんじゃないだろうか。

988 ：デフォルトの名無しさん：2008/09/02(火) 23:32:57

>>985
プロパティ構文が一番じゃね?

989 ：デフォルトの名無しさん：2008/09/02(火) 23:36:31

こいつの主義からすれば、func.invoke(aho) じゃなくて、func(aho) とやりたいってのじゃないの？

どうせスカラー云々スクリプト云々って奴だろｗ
こいつの頭の中ではごっちゃになってて、サル脳だから理解できないんだろうｗｗ

990 ：デフォルトの名無しさん：2008/09/02(火) 23:58:48

>>987
たいして仕様を読んでないようなサルの相手をすることもないんじゃないの？
君も同じく相当ヒマだろうけどｗ

991 ：デフォルトの名無しさん：2008/09/03(水) 01:37:33

このスレって偉そうに言ってる奴はどこが悪いのか指摘すらできないんだよなwwww

992 ：デフォルトの名無しさん：2008/09/03(水) 01:39:55

>>990
なら仕様を読みまくってる君が簡潔に説明してみたらいいのではないだろうか
なんでここ見てるわけ？

993 ：デフォルトの名無しさん：2008/09/03(水) 01:45:49

>>991,992

くやしいのｗｗｗくやしいのｗｗｗｗｗｗ