06/05/18 01:03:42
前スレ
【Java】次世代Java・J2SE1.6の動向【Mustang】
ｽﾚﾘﾝｸ(tech板)
関連スレ
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
ｽﾚﾘﾝｸ(tech板)
URLﾘﾝｸ(www.itmedia.co.jp)
マルチタスク実現へJava言語改良
Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、
Javaバーチャルマシン（JVM）のアプリケーション共有を強化する「分離」機能が備わり、
ローカライズコンピューティング処理実行のための分離が可能になるという。
米Sun Microsystemsは、Javaバーチャルマシン（JVM）内部での
アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。
カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。
SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、
今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、
JVMのアプリケーション共有を強化する「分離」機能が備わる。
この機能によってローカライズコンピューティング処理実行のための分離が
可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。
またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする
Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、
J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。
2:デフォルトの名無しさん
06/05/18 01:05:40
トラックバック:ｽﾚﾘﾝｸ(tech板)
以下のスレは、埋まったら今度はこのスレを本スレとしませんか？
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
ｽﾚﾘﾝｸ(tech板)
3:デフォルトの名無しさん
06/05/18 01:10:17
マ板のスレみたいな名前だからなぁ・・・
4:デフォルトの名無しさん
06/05/18 01:15:46
アンチ厨が群がってくると？
マ板とは区別できるだろうと期待したい。
馬鹿には馬鹿しか集まらないが、
知的な議論が交わされれば
オッサン共はこちらを荒らすことは無いだろう。
もしこっちがあれたらム板のC言語やC++スレ、C#スレまで
荒れることになる恐れがあるので。
5:デフォルトの名無しさん
06/05/18 03:23:27
現代から次世代、次々世代まで
Tiger JDK5.0
URLﾘﾝｸ(java.sun.com)
言わずもがな、リリース最新バージョン
Mustang JDK6.0
URLﾘﾝｸ(java.sun.com) [beta]
URLﾘﾝｸ(mustang.dev.java.net) [weekly binary snapshot]
URLﾘﾝｸ(java.sun.com) [Version6 or 1.6?]
おお、JavaOne期間でロゴ変わってる
Dolphin JDK7
URLﾘﾝｸ(dolphin.dev.java.net)
まだ、できてない、2006年春スタート予定だったはず。
>>1 の話ってちょいと昔のかなぁ、と思いつつ・・・
BercelonaプロジェクトのMVMの話、どうなってんだろ、と思い出した
つ URLﾘﾝｸ(research.sun.com)
まだまだ研究レベルで、実際はDolphinで載ればいい方かな、と思ってんだけど。
Dolphinは、言語スペックに大幅改修入るみたいだし、なんとか一緒に入るのかな？
実現されればWebサーバ側で、JVMがデーモンのように上がってる、なんて事になったりして・・・
6:デフォルトの名無しさん
06/05/18 19:22:03
Mustang ベータ2が来月。リリースが9月だっけか。。
Dolphinは2008年半ばだそうな。
7:デフォルトの名無しさん
06/05/18 19:41:51
Windows Vistaへの対応が気になるところ。
Windows版だけ、6月無理とか、制限あったりとかしそうな悪寒。
8:デフォルトの名無しさん
06/05/18 20:02:09
Vista発売の方が延びるから問題ない。
9:デフォルトの名無しさん
06/05/18 20:03:17
Vista 対応って、具体的に何を期待してんだろ？
10:デフォルトの名無しさん
06/05/18 20:17:37
XP SP2上と同じように動くこと。
現状、Vista公開β候補版でボロボロなので。
11:デフォルトの名無しさん
06/05/18 22:17:28
URLﾘﾝｸ(journal.mycom.co.jp)
＞Mustangの次のバージョンのJava SEはDolphin(Java SE 7)である。DolphinではJavaプ
＞ラットフォームがエコシステムへと発展する方向での拡張を目指すという。具体的にど
＞のような拡張が行われるのかは現在議論が重ねられている最中だが、現時点では次
＞のような新機能の追加が発表されている。
＞
＞プロパティのサポート
＞メソッドリファレンスのレポート
＞クロージャのサポート
＞言語レベルでのXMLのサポート
＞JVM上で動作する動的言語のサポート
＞スクリプト言語サポートの拡張
＞モジュール化のサポート
＞Swingアプリケーション開発のためのツールの充実
Dolphinってこんなに変わるのかよ。プロパティ・サポートとかクロージャのサポートって、
かなり大きな変更のように思うが...
12:デフォルトの名無しさん
06/05/18 23:47:51
クロージャってC# 2.0の匿名メソッドみたいなｱﾌｫなものに
なるんだろうな。
URLﾘﾝｸ(d.hatena.ne.jp)
VM自体がクラス前提になっているから、猛烈にクソなものが平気で
出てくる。
13:デフォルトの名無しさん
06/05/19 00:00:07
>>12
なんでいきなり言い切ってるんだろうか....
C#がクソな実装したからってJavaがそうなるとは限らんだろうに。
実際、いままでJavaの実装で、このC#のようなクソな実装ってあったか？
おれはもしJavaで同じことやったら、実行速度上のデメリットがあっても、
ソースコードとの一致を取って、ループの度に匿名インスタンス生成を
選択するんじゃないかと思う。
それがMS一社で決めてるC#と、コミュニティで決めてるJavaの違いじゃ
ないかと。
14:デフォルトの名無しさん
06/05/19 00:27:05
それってruby の yield?
Genericsみたいにもめても、何とかなるんじゃない？
15:デフォルトの名無しさん
06/05/19 01:49:07
>>13
Generics
16:デフォルトの名無しさん
06/05/19 01:53:58
GenericsってJavaのほうが実装早いだろ
17:デフォルトの名無しさん
06/05/19 01:56:46
Genericsはそんなにクソでもないと思うがなあ。
イレイジャのこと言ってるんだけど、妥当な妥協ポイントだと思うよ。
おかげでcommonsとかそのまま使えてるわけで。
18:デフォルトの名無しさん
06/05/19 03:37:39
>>11
この新機能ってJSRで言うとどれなのかリストあるのかね?
19:(・∀・)ｷﾀｺﾚ!!
06/05/19 12:01:51
「あとは方法を検討するだけ」--サンがJavaのオープンソース化を約束
URLﾘﾝｸ(japan.cnet.com)
20:デフォルトの名無しさん
06/05/19 12:19:32
要は不良債権処理でしょ。マクネリもクビ切られるほどSunがヤバイ状況だから。
21:デフォルトの名無しさん
06/05/19 13:21:22
まくにーりーって会長職にいるんだけど・・・？
22:デフォルトの名無しさん
06/05/19 17:31:28
Linuxディストリにも標準バンドルされる、というのは良いことだな。
23:デフォルトの名無しさん
06/05/19 17:34:01
>>19
会場盛り上がったよ
>>21
明日出てくるよ
24:デフォルトの名無しさん
06/05/19 20:21:37
「JavaVMは汎用OS上で動かさない」---JRockitの開発マネージャにJavaVMの今後を聞く
---今，JavaVMにどんな機能が求められているのか
環境の変化に対応しなければならない。それは「サーバー仮想化」という動きだ。
VMwareやXenなどのHypervisor技術に基づいた仮想化ソフトを利用するケースが増えている。
一つのハードウエア上で多くのアプリケーションを動作させることになるが，
単に動作させるだけでなく，アプリケーション間の干渉がないようにすることが求められている。
そのためにはアプリケーションごとにリソースを制御しなければならない。
---リソースの割り当てはOSが担うのではないのか
その通り。だが汎用OS（WindowsやLinuxなど）では力不足だ。実行時に（プロセスごとの）
優先順位を付けることはできるが，一定量の（メモリー，CPU，ネットワーク帯域などの）
リソースをアプリケーションに確実に割り当てることはできないのが実情だ。状況によっては，
メモリー上のデータがディスクに書き出されてしまうこともある。そうなれば性能は大きく低下する。
---そうした問題をどうすれば解決できるのか
“汎用OSを利用しない”というアプローチがある。それを当社では進めている。ハード
ウエア上でHypervisor（技術に基づいたソフト）を動作させ，その上にJavaVM専用のOS
「Bare Metal」（開発プロジェクト名），さらにその上でJavaVMを動作させる。そのよう
な動作環境において，JavaVMごとにリソースを確実に割り当てるという方法だ。汎用OSを
利用しないので確実にリソースを割り当てることが可能だ。JavaVMから見るとBare Metal
はOSに見えるが，汎用OSの機能は備えず，一つのJRockitプロセスを動作させるのに必要
な機能のみ提供する。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
25:デフォルトの名無しさん
06/05/19 21:08:00
>>24
つまりどうなるの？
VMとOSの間に仮想化ソフトをかますってこと？？
26:デフォルトの名無しさん
06/05/19 22:31:44
JRockitって、いつの間に無償になってたんだ
27:デフォルトの名無しさん
06/05/19 23:05:29
>>12
>>13
なんかあちこちで勘違いされてるっぽいけど、C#2.0の匿名デリゲートの
仕様は、(レキシカル)クロージャとして妥当だよ。レキシカルクロージャは、
(実行時ではなく)生成時の環境をキャプチャするので、>>12のリンク先の
ような挙動は、極めて普通。Schemeのlambda式によるクロージャや、
RubyのProcオブジェクトによるクロージャの挙動と基本的には同じ。
28:デフォルトの名無しさん
06/05/19 23:22:58
あと、C#の匿名デリゲートの振る舞いについては、langsmith MLの197から
始まっている議論が参考になると思う。
29:デフォルトの名無しさん
06/05/19 23:32:53
そもそもレキシカルスコープというもの自体が、プログラマの感覚から
離れててコンピュータの都合に合わせているもののように思う。
30:デフォルトの名無しさん
06/05/19 23:53:35
>>29
そういう考え方ができないとは言わないけど、歴史的に見れば、逆だと思う。
プログラマの都合に合わせるためにできたのが、レキシカルスコープ。
初期のプログラミング言語のほとんどが、グローバルスコープしか無い
のに対して、最近の言語のほとんどがレキシカルスコープを採用している
のも、それを示していると思う。
31:デフォルトの名無しさん
06/05/20 00:00:49
レキシカルスコープだけに歴史・・・いやなんでもない
プロパティサポートとか次世代の話続けて
32:デフォルトの名無しさん
06/05/20 00:16:20
じゃあ、プロパティの話を。プロパティ自体は、そんなに大きな変更ではない
と思うけど、どうやって取り入れるんだろうね。簡単に考え付くのが、Groovy
みたいにx.hoge -> x.getHoge()、x.hoge = y -> x.setHoge(y)とコンパイラが
変換するというもの。これなら言語仕様の変更は最小限で済みそうだし、
Java VMも変更する必要が無い。ただ、プロパティと同名のフィールドが
あった場合にどちらを優先するか、とかいくつか考えることはあるが。
33:デフォルトの名無しさん
06/05/20 00:34:59
>>30
すまん、Perlでいえばlocalとmyを逆に考えて書いてしまった....
レキシカル＝ローカル だよな。
しかし>>12の例で言えば、
delegate { Console.Write ("{0} ", i); };
ってのは、ループカウンタ i の値をクロージャというもんのコンストラクタに渡したような
もんであり、 i という変数を渡したわけじゃないんじゃないか？
i がそのまま参照として渡されたような印象をうけるC#の動作の方に違和感があるん
だけど。
34:デフォルトの名無しさん
06/05/20 00:36:55
またレキシカルの話題をかいちゃったので、プロパティの話も書くね。
おれはGroovyの@Propertyみたいなのを採用するのかな、と思う。
>>32のいうように、x.hogeとかいう部分はあくまでx.getHoge()のままで、
getter/setterの定義を「@Property hoge」みたいな感じで定義できる、
とかシンタックスシュガー的なもんなのかなあ、と。
35:デフォルトの名無しさん
06/05/20 00:40:53
モジュール化の話は詳細が出てたね。
共有ライブラリで、外部に提供する関数名を限定できるみたいに、
どのクラス、どのメソッドをエクスポートするか定義できるようになる
みたい。
パッケージにスーパーパッケージみたいなものを定義できて、そのなかに
複数のパッケージをまとめて、しかも外部から見えるのはこのクラスとこの
クラスね、とかやれるみたいだね。
Perlのモジュールと似たような感じかな？
一番よくわからん項目は「メソッドリファレンス」かなあ。これなんだろ。
おれは>>11に載ってる項目よりも、NIO2がいつになったら出るのかもう、
待ちくたびれるっつうの。はやくJavaからファイルのメタデータにアクセス
できるようにしてくれよ。
36:デフォルトの名無しさん
06/05/20 00:59:44
>>33
> delegate { Console.Write ("{0} ", i); };
> ってのは、ループカウンタ i の値をクロージャというもんのコンストラクタに渡したような
> もんであり、 i という変数を渡したわけじゃないんじゃないか？
レキシカルクロージャと言った場合、一般的には、まさにiという変数
そのものを渡すようなものを指す。もっと知りたい場合は、Schemeや
Rubyなどの、クロージャを持っている他の言語について調べてみると
良いと思う。
ちなみにこのような仕様になっていることによって、どんなメリットがある
かというと、例えば、次のような「制御構造」を抽象化したライブラリを
作れるという点が挙げられる。JavaやCなどの言語では、制御構造は
あくまで組み込みのものだけど、クロージャがある言語では、新しい
制御構造を提供するライブラリを簡単に作ることができる。
int sum = 0;
list.each(delegate(int i){
sum += i;
});
Console.WriteLine(sum);// listの要素の合計を出力
37:デフォルトの名無しさん
06/05/20 01:05:54
getとsetでプロパティがいいと思います
38:デフォルトの名無しさん
06/05/20 01:18:59
>>36
あ、なるほど、sumという外側のローカル変数そのものが渡っているというイメージね。
参考になったよ。逆に言えば、もともとアクセスできるものを引数で渡している>>12の
例が、ちょっと使い方を誤ってるということかな。
39:デフォルトの名無しさん
06/05/20 02:10:42
言語レベルでのXMLのサポートって、
E4Xみたいなもんが乗るのかな？
40:デフォルトの名無しさん
06/05/20 02:24:26
>>39
なんか、文字通りJavaのソースの中にXMLをそのままかけるらしいぞ。
イメージ的には
XML data = <test><dataset><key name="test"><value>test</value></key></dataset></test>
とかそのまま書けるって感じというか。
正直、まだ利点を見いだせない。シンプルなjavaを複雑にしてないだろうか？
41:デフォルトの名無しさん
06/05/20 02:28:51
VB9にも似たのがあった気が。
誰がつかうんだろう
42:デフォルトの名無しさん
06/05/20 02:29:20
Java的には、クロージャって引数の数によって識別されるRunnableが
あって、いままでいろんなものでそれぞれリスナを作ってたところを、
そういう共通的なRunnableを使って実装する、というイメージなのかな、
という気がした。
inputFile.eachLine( closure(String line) { 行の処理 });
ってなことだよね？
43:デフォルトの名無しさん
06/05/20 02:29:39
そんなん入れるならヒアドキュメント入れろ
44:デフォルトの名無しさん
06/05/20 02:31:34
>>40
またパ...
45:デフォルトの名無しさん
06/05/20 02:37:03
まあ
なんたら.execute(
new Runnable() {
public void run() {
ほげほげ
}
});
って長くてうざかったし、そのシンタックスシュガーを提供してくれる
だけでもうれしいかな。
Wicketだとこの手の書き方大量にするんで....
);
46:デフォルトの名無しさん
06/05/20 04:18:37
もうJavaの拡張はいいよーまた覚えることが増えるだけじゃん
こんなの初心者はついていけないぞ。教えきらん。
>>34
俺もそう思う。たんにgetter/setterの定義を書かなくて済むようになるだけで、
x.getXxx() が x.xxx と書ける訳じゃないと思う。そこまで気が利くとは思えん。
>>36
その例は「制御構造」とはいわないのでは？いうのかな？
>>40
はげどう。JSONサポートならほしいけど、XMLサポートはいらね。
>>43
うおー超はげどう。ヒアドキュメントはだれも要求しないのか？
47:デフォルトの名無しさん
06/05/20 04:46:50
>>46
いや、 x.xxxだったらpublicのフィールドあったときかぶっちゃうじゃない記法ｗｗｗ
48:デフォルトの名無しさん
06/05/20 05:48:38
>>47
publicのフィールドがあればそっちをつかう、なければsetter/getterを使う、というルールでいいんじゃない？
あるいは逆に、setter/getterがあればそれをつかい、なければフィールドを探すか。
どっちにしろ、どうルールを決めるかの問題。
いらないけどね。
それより、配列や文字列の長さをELからも参照できるようになってほしい。
str.getLength()じゃなくてstr.length()だから、ELからはstr.lengthとは参照できない。
関数使わなきゃいけないのなんてかっこわるい。全然オブジェクト指向じゃない。
49:デフォルトの名無しさん
06/05/20 08:55:32
シンタックスシュガーでいいのでは？
だからべつにgetやsetをかくと重複していますというエラーがでればいい
isをどうするかは今でも同じ話だしな
互換性を考えればコレしかないかと
どのみちIDEの機能で意識はしてないけど、プロパティ扱いでまとめてくれると見やすいからね
折りたためるようになってくれればいい
50:デフォルトの名無しさん
06/05/20 09:32:17
>>36
その例は「レキシカル」クロージャの有益な例にはなってないよね。
クロージャの有益な例というだけで。
>>30
それは少し極端かな。両方の理由があった。
効率のいい実装、デバッグしやすい意味など。
51:デフォルトの名無しさん
06/05/20 09:45:30
>>48
そのlengthもプロパティで解決だね。
>>35
メソッドリファレンスは、
単純な(doAction()のみなど)Listenerを設定する時に、
extends ～Listenerなクラスを定義しなくても、
既存のクラスのメソッドをそのまま指定できるんでしょ、たぶん。
C++でいうところのstd::mem_fun_refじゃないかと。
boost::signalsと一緒に使ったりする。
52:デフォルトの名無しさん
06/05/20 11:16:08
>>40
そいで for (XML d : test.dataset[0].key) { System.out.println(d.key.value); }
とかアクセスできたらまんまE4Xじゃないか。俺的には超OK。
53:デフォルトの名無しさん
06/05/20 11:59:47
>>50
36だけど、例として挙げたプログラムだと、レキシカルクロージャの特徴で
あるキャプチャされた変数が無限の寿命を持つという点を生かしてない
という話かな？確かにその通りではあるんだけど、それを生かしたプログラムは、
Schemeではよく出てくるけど、C#ではオブジェクトがあればほとんどの場合、
代用できてしまうので微妙かなと思う。
54:デフォルトの名無しさん
06/05/20 12:02:43
>>52
その例を見て思ったんだが、もしかして、プロパティの導入目的は、
言語レベルでのXMLのサポートを、より効果的に行うためなのかも。
55:デフォルトの名無しさん
06/05/20 13:00:54
>>53
そう。あとdynamic bindingでも、lexical bindingでも同じ意味。
Schemeのようなクロージャは強力すぎるけど、
C++の式テンプレートくらいの機能は欲しいなあ。
C#の匿名メソッドは、>>12のページにあるように、
引数に与えられた式を使ってクラスを定義するみたいだから、
変数や関数の参照は、名前呼び出し風って事になるのかな。ちょっと使いにくそう。
> オブジェクトがあればほとんどの場合、代用できてしまう
まさに式テンプレートですね。
Javaに式テンプレート入れると、型システムのルールが、
クロージャの引き数のところだけ変わるから無理そうだけれども…
56:デフォルトの名無しさん
06/05/20 15:32:18
>>55
>そう。あとdynamic bindingでも、lexical bindingでも同じ意味。
確かにそうだね。というわけで、dynamic bindingじゃできない例を作ってみた。
クロージャの話でよく出てくる古典的な例なので、またかよって思うかもしれんが、
そこは見逃してくれるとありがたい。Converterってのは、.NET Framework 2.0
で入ったdelegate型で、ある型を受け取って別の型(同じ型でもいいけど)を返す
メソッドを表す型ね。
using System;
class TestLexicalClosure {
/* カウンタを作って返すメソッド */
static Converter<int, int> Counter(int start){
return delegate(int n){ return start += n; };
}
static void Main(string[] args){
Converter<int, int> counter = Counter(0); //カウンタを作る
Console.WriteLine(counter1(1)); // => 1が表示される
Console.WriteLine(counter1(2)); // => 3が表示される
}
}
> 引数に与えられた式を使ってクラスを定義するみたいだから、
> 変数や関数の参照は、名前呼び出し風って事になるのかな。ちょっと使いにくそう。
これは意味がよくわからなかった。もうちょっと詳しく言ってくれるとありがたい。
57:デフォルトの名無しさん
06/05/20 15:34:32
ミスった。counter1って書いてあるところは、counterの間違い。
58:デフォルトの名無しさん
06/05/20 16:49:51
もう、マクロでよくね？
59:デフォルトの名無しさん
06/05/20 17:32:29
>>56
class TestLexicalClosure {
int _start;
/* カウンタを作って返すメソッド */
static Converter<int, int> Counter(int start){
_start = start;
return delegate(int n){ return _start += n; };
}
じゃなくてもいいの?
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(ant0x.udap.jp)
URLﾘﾝｸ(www.divakk.co.jp)
とか読むとめまいしてくるんだけど…
結論としてはC#のanonymous methodと同じものならJavaにはいらない。
60:デフォルトの名無しさん
06/05/20 17:57:00
>>59
55のコードで大丈夫。実行して、ちゃんと動作することも確認した。
あと、59のコードだと、複数のCounter()を複数回呼んで、複数個の
カウンタを作っても、カウンタの値が共有されてしまうので、まずい。
ポイントは、匿名デリゲートから参照されている外側のローカル変数は、
それが宣言されたスコープを抜けても生きているということ。
>とか読むとめまいしてくるんだけど…
>結論としてはC#のanonymous methodと同じものならJavaにはいらない。
俺はむしろC#のanonymous method的な振る舞いじゃないと嫌だなあ。
あと、anonymous method(というかクロージャ)の振る舞いに関して、
どの辺がめまいがすると感じた？
61:デフォルトの名無しさん
06/05/20 18:39:43
あのコードみて問題ないと感じるのがすごいな
なぜそうなるかは実装側の都合という状態
62:デフォルトの名無しさん
06/05/20 18:43:16
一番内側のブロックがクラスに変換されるの? > 匿名メソッド@C#
>>59の二つ目のページ読むとそんな感じなんだが。
>>56では、Counter()が一番内側のブロックだから、
引数は変換されたクラスのメンバ変数になるってこと?
63:デフォルトの名無しさん
06/05/20 20:30:15
>>61
>>59の3番目のリンク先は、仕様書のバグということで問題だと
思うが、1番目と2番目のリンク先の挙動は、本当に問題無いよ。
実装側の都合でそうなっていると勘違いしているようだけど、
レキシカルクロージャになるように匿名delegateを実装したら
そのような実装になったというだけのこと。あと、1番目のリンク先
の人はレキシカルクロージャという概念を勘違いしてて、コメント
欄で突っ込まれまくってる。
>>62
実装としては、一番内側のブロックが…とかいうのではなく、匿名
デリゲートから匿名デリゲートの外側のローカル変数を参照していた
場合、参照されている変数をメンバ変数として持つクラスが生成される
ということ。
64:デフォルトの名無しさん
06/05/20 20:37:29
>>63
いや、なぜそうなるか、は昔からいわれてたけど
それが本当に書く人が理解でき照るかというのとは別だと思う
書いた本人ならまだしも、他人のコードをさらっと斜め読みして
結果を予想できるかという割れると厳しいかも
65:デフォルトの名無しさん
06/05/20 20:45:13
>>64
> それが本当に書く人が理解でき照るかというのとは別だと思う
それは確かにその通りだけど、このスレではなんか、匿名delegateの
セマンティクスが実装の都合だという風に誤解されてるようなので、
それは違うんだと言いたかった。
> 書いた本人ならまだしも、他人のコードをさらっと斜め読みして
> 結果を予想できるかという割れると厳しいかも
レキシカルクロージャという概念に馴染みの無いユーザが驚く可能性は
あるかもしれないけど、よっぽどトリッキーな使い方をしてない限り、
どう動くかというのは、簡単に予想できるんじゃないかなあ。
66:デフォルトの名無しさん
06/05/20 21:19:49
二つ目のページで、
static D[] F() {
D[] result = new D[3];
int x;
for (int i = 0; i < 3; i++) {
int y = i * 2;
x = i * 2;
result[i] = delegate { Console.WriteLine(x + y); };
}
return result;
}
だと、[4 6 8](=[0 2 4]+[4 4 4])なんだろ?
変換結果のILはどうなるんだ?
メソッドb__0()は、xとyをどうやってaccessするんだ?
別のインスタンス内にあるはずだが…(宣言のある場所で閉じ込めるインスタンス生成)
それとも「一番内側の」ブロックで生成するインスタンスに全部含めるのか?
そうすると[8 8 8]か?
67:デフォルトの名無しさん
06/05/20 21:48:53
delegate自体C#の構文はよくないねぇ
68:デフォルトの名無しさん
06/05/20 22:27:16
>>66
ILを含めると長くなるので、その辺は省略して、宣言だけ示すと、大体こんな感じになる。
DisplayClass3のフィールドとして、DisplayClass1のフィールドを持っているので、b__0(匿名
デリゲートのコード本体)からはxとy両方にアクセスできる。
class <>c__DisplayClass1 {
public int x;
}
class <>c__DisplayClass3 {
public DisplayClass1 <>8__locals2;
public int y;
void <F>b__0(){/* 匿名デリゲートの中身が入る */}
}
というわけで、結果は[4 6 8]で正しい
69:デフォルトの名無しさん
06/05/20 22:36:35
苦労じゃなんて使うんかい
70:デフォルトの名無しさん
06/05/21 03:36:44
おればかだから>>12,27,33,36の話がよくわかんなくて、groovyでコード
>>12の参照先とほぼ同じ書いてみてやっと分かった。
def closures = []
for( i in 0..10) {
closures[i] = { println i }
}
for( c in closures) {
c()
}
結果は同じように10がずらっと表示された。
これは、closuresに入っている各クロージャは、クロージャ外側の変数 i に
そのままアクセスできるわけだけど、実際に実行されるc()の段階では、
i は既に10になっちゃってるから、これがずらっと表示されると考えて
やっとしっくりきた。
>>56は
def makeCounter( start) {
return { n -> return start += n }
}
def closure = makeCounter(0)
println( closure(1))
println( closure(2))
ってな感じなんで、つまりクロージャから参照された変数 start は、変数自体がスコープを
越えてもクロージャ内では普通につかえるし、クロージャがある限り存在しつづける、と。
インナークラスがエンクロージングクラスのインスタンス変数にアクセスできるようなもん
だけど、クロージャにはクロージャのスコープがあるので、一度クロージャが使った変数は
クロージャ内で存在し続ける、ということか。
71:70
06/05/21 03:37:53
groovyでコード>>12の参照先とほぼ同じ書いてみて
↓
groovyで>>12の参照先とほぼ同じコード書いてみて
72:デフォルトの名無しさん
06/05/22 23:01:22
んで、結局Dolphinで対応されるのは
どういう機能なわけ。まだ曖昧にも決定してない？クロージャって単語だけが歩いてる？
73:デフォルトの名無しさん
06/05/23 03:13:41
匿名クラスのシンタックスシュガーには間違いなさそうだな。
74:デフォルトの名無しさん
06/05/25 06:26:42
嬉しい誤算発見
JavaでのサブピクセルAAレンダリングはJavaのレンダリング使うからか
リモートデスクトップ経由でも有効だね
ピクセルの構成が一致してないとつらいとは思うが
75:デフォルトの名無しさん
06/05/26 01:39:14
プロパティマンセー
obj.setWidth(obj.getWidth() + 1)) なんて書かなくてもよくなりてぇえええ
76:デフォルトの名無しさん
06/05/26 04:15:52
じゃ、
obs.width = obj.width +1 ;
になるわけか・・・・
なんか、VBのProcedureみたい。(VB4の知識で書いてます悪しからず)
77:デフォルトの名無しさん
06/05/26 06:14:57
>>75,76
ほんとにそうなるの？
おれはgetter/setterの定義を書かなくて済むようになるだけだと思ってた。
ソースきぼん。
78:デフォルトの名無しさん
06/05/26 08:33:46
>>77
むしろそっちがソースｷﾎﾞﾝ。
getter/setter だけなんて、中途半端じゃん。
79:デフォルトの名無しさん
06/05/26 09:09:56
>>78
いや、ソースはない。「プロパティがサポートされる」と聞いて、どうせgetter/setterが自動生成される程度で、getXxx()/setXxx()は使わないといけないのだろうと思った。それだけ。
80:デフォルトの名無しさん
06/05/26 13:25:01
>>79
getter/setterの定義よりも、それらにアクセスするコードを書く回数の方が
圧倒的に多いので、getter/setter自動生成だけだと、新しい言語機構を
導入するメリットが少なすぎる。だから、たぶんアクセスするときの便宜も
図られるんじゃないかなあ。
81:デフォルトの名無しさん
06/05/26 13:54:31
こんなんもいけるんかのう？
obs.width++;
82:デフォルトの名無しさん
06/05/26 15:16:13
>>78
ライトアクセスとリードアクセスを区別して grep できないのはやだなぁ。
83:デフォルトの名無しさん
06/05/26 18:35:27
>>82
呼び出し階層の検索でいけるんじゃないの？ たぶん。
あ、ごめん、これはEclipseの話だな。。。
84:デフォルトの名無しさん
06/05/26 23:12:33
とはいえピリオドでやっちまうとメンバ変数のwidthとgetWidthメソッドとの判断が難しいよな
obs@widthとかobs->widthとかなんか特殊な構文が追加なのかも
getsetかかせるよりはいいけどね
85:デフォルトの名無しさん
06/05/26 23:26:41
>>84
C/C++ で使われてる -> よりは @ に賛成。
Character.isJavaIdentifierStart('@') も false 返すみたいだし、
やろうと思えばできるのかな？
あと、JSR 295 見ると、converter や validator 使って何かやるみたいね？
obs@width = "120"; とかやると勝手に StringToIntegerConverter を
使ったコードを挿入してくれるのかな？ とか妄想してみる。
86:デフォルトの名無しさん
06/05/27 00:14:26
245なんかのProperty Resolver APIが言語に入るんでしょ。
operator.のoverload。
Property Binding API, Method Biding APIなんかも。
87:デフォルトの名無しさん
06/05/27 11:49:33
>>80
Javaにそんな気の利いたことを望んではいけない。
ヒアドキュメントすらない言語だ、「互換性」を楯にして、最小限の使用追加だけですませるだろう。
しかしほんとに後付けの機能がふえるよな。もうぜんぜんシンプルな言語じゃなくなった。
88:デフォルトの名無しさん
06/05/27 11:58:45
プロパティに関しても1.1での後付考えかただし1.0はアルファ品質だったしな
それでもプロパティはEODでは？
用意するほうはIDEがやってくれるけど使うほうが原始的杉
Genericsは開発効率がよくなりバグが大幅に減るすばらしいものだが
落ちこぼれるやつが多数いる
この程度でおちこぼれるのならそいつはこの業種向いてないとは思うのだが
ひとつの判断材料にはなるかも
lockはsynchronizedのように専用構文がないと厳しいような
なんでもそうだが資源解法でfinallyあてにするのは苦しいよな
89:デフォルトの名無しさん
06/05/27 12:01:11
いますでにgetXXX, setXXXの存在を前提として作られているフレームワークが
やまほどあるので、基本的にはシンタックスシュガーになるんだろうな。
obj.prop = xxx とか書くにしても、バイトコード上では setProp(xxx)になってるとか。
90:デフォルトの名無しさん
06/05/27 12:07:39
そりゃそうだろ
91:デフォルトの名無しさん
06/05/27 12:21:18
>>88
俺はC++も好きなタイプなので、
Javaの言語領域で機能増えるのは嬉しい気持ちもある反面、
やりすぎて失敗しないのを祈りたい気持ち。
既に十分複雑だからね。抱えているプログラマ層を考えると。
92:デフォルトの名無しさん
06/05/27 13:03:03
Perlがあんだけ使われてるのみると、記号が増える分には問題なさそうだ。
93:デフォルトの名無しさん
06/05/27 13:36:50
ヒアドキュメントって、国際化対応とかどうするの？
94:デフォルトの名無しさん
06/05/27 17:59:29
それでなくても、ヒアドキュメントなんか、めったに使わないからな。
めったに使わないもののためにコンパイラ作りにくくすることもない。
95:デフォルトの名無しさん
06/05/27 19:15:47
ヒアドキュメントはあかんでしょ
なんでヒアドキュメントかっていうと基本的に書く側の都合じゃない
そこに書きたいっていう。
視認性は悪くなるし文法なんて無茶苦茶。
あれを使いたくなる理由は、簡易テンプレートエンジンとして使えるからだと思うんだけど
テンプレート処理がしたいんだったらIDEとか開発ツールのアシストで
何とかなると思うんですけどね。
ScriptingAPIと同じ扱いでいいんじゃないかと思う。
あれも構造が類推できないスクリプト言語がソースにヒアドキュメント形式で生で埋め込まれてたらと思うとぞっとする・・・
96:デフォルトの名無しさん
06/05/27 19:54:22
>>94
ちょっとまて、ヒアドキュメントごときでなんでコンパイラが作りにくくなるのだ？
あんなの、字句解析部をちょこっといじれば済む機能だぞ。
おまえ、コンパイラの作り方もわかってないだろ。
>>95
ヒアドキュメントで済むことをIDEとか開発ツールのアシストを使わなきゃいけないということに疑問をもたないのか。
HTMLページをまるごと埋め込むのならアホだけど、テストデータとその期待値を埋め込むのなら
ヒアドキュメントはすごい便利なんだけど。
つーか、「そんな機能必要ない」「IDEのサポートがあれば十分」とかいってるやつらって、実際その機能が追加されたら「これはEoDを実現するすばらしい機能だ」とか言い出すんだろ。
Genericsだって、最初は「C++のテンプレートは複雑だから同じような機能はJavaには必要ない」とか揃っていってたくせに、いざ実装されるとみんなGenericsマンセーなんだよな。
プロパティだって、今までgetterとsetterはEclipseが自動生成してくれるから問題ないとか言ってたくせに、それが実装されると「これは便利だ」とか言い出すんだぜ、絶対。
Javaにない機能は「そんなの必要ない」と言い切り、実装されれば「すばらしい進化だ」と手のひらを返す。ほんと学習しねーよな。
>>93
なんで国際化が必要なん？ふつうにStringリテラルと同じ扱いでいいじゃん。
97:デフォルトの名無しさん
06/05/27 20:01:41
ヒアドキュメント作るとして、懸念があるとすれば改行記号の扱いぐらいかな？
98:デフォルトの名無しさん
06/05/27 20:02:14
>>96
だから当時「いらない」と言ってた人たちは恥ずかしくなって黙ってしまって、
今度は別の人が別の機能に「いらない」といってる、くらいの想像力はないのか？
実際まったく同じ人だったらキモイだろう。
ヒアドキュメントはあれば便利だと思う。
一方でコンパイルされたバイトコードの中（つまりはclassファイル）の中に
そのヒアドキュメントの内容が埋め込まれるんだったらダサすぎなのでペケかな。
99:デフォルトの名無しさん
06/05/27 20:04:24
>>96
> 最初は「C++のテンプレートは複雑だから同じような機能はJavaには必要ない」とか
そんな阿呆な事言ってた奴は居るのか？
少なくとも俺は聞いたこと無いぞ。
erasure よりマシな実装方法もあったんじゃないの？ って話なら結構聞いたけど。
100:98
06/05/27 20:07:46
あ、しかしまあ、String document = ""が自動生成されると考えると
さほどヘンでもないか。
しかし一方で、ヒアドキュメントってドキュメント中に変数値を簡単に
埋め込めないとあまり使い道がないと思うんだがどうだろうね。
式言語っぽく${変数名}なんてのを採用すると、式言語パースが必要に
なるかな。
101:デフォルトの名無しさん
06/05/27 20:15:06
Stringで生成されるなら%dとか%sでいいだろ
何のためのフォーマッタだ
102:デフォルトの名無しさん
06/05/27 20:25:12
それだとあとから変数をセットしなくちゃいかんじゃないか。
103:デフォルトの名無しさん
06/05/27 20:43:44
>>102
そういうことなら、ドキュメントの生成とその中の文章の埋め込みまで
やっちゃわないと駄目ね
>>96
そのアホが出てくるからコードのメンテナンス性が落ちちゃうんだよなぁ
でもそれは、コーディング規約でやらないようにさせるっていうのなら
ツール用意して・・・・っていう話と比べてもどっちもどっちだと思うが
他の言語で利用されて便利なヒアドキュメントのいいところだけをＪａｖａらしく取り込んでくれれば
いいとは思う。
特殊なコメント記法を入れて、コメントを識別子つけて参照できるようにするってのはどうかな？
/***
<html><body>
ほげひげは、${age}歳です
*/
あ、名前つけんのどうしよう
それよりは、特殊な改行付き文字列定義をかけた方がいいか・・・・
String document = '''
<html>ほべー
げれげれー
</html>''';
うーん、ターミネータがきめうちなだけのヒアドキュメントになったぞ。
104:デフォルトの名無しさん
06/05/27 23:11:41
>>96
> なんで国際化が必要なん？ふつうにStringリテラルと同じ扱いでいいじゃん。
そりゃそうだよね。
javacのソースの文字コード、
Shift_JISがディフォールトなのそろそろやめてくれないかな…
105:デフォルトの名無しさん
06/05/27 23:13:48
>>104
なにいってるの？
106:デフォルトの名無しさん
06/05/27 23:40:47
javacのソースの文字コードのデフォルトは、プラットフォームのデフォルトと
一致している予感。
107:デフォルトの名無しさん
06/05/27 23:41:29
>>104
LANG=ja_JP.UTF-8
export LANG
108:デフォルトの名無しさん
06/05/27 23:59:04
>>107
どこのJDKよ?
109:デフォルトの名無しさん
06/05/28 00:09:32
馬鹿が涌いてるな。
110:デフォルトの名無しさん
06/05/28 00:13:00
>>99
そうだね。Genericsに関しては、初期の頃からJavaプログラマの間でも、
Javaの欠点として言われていたし、Javaを拡張してGenericsを導入して欲しいという
提案も比較的初期の頃からあった。まあ、最近になってJavaにかぶれた人で、
ひょっとしたらそういう人は居るかもしれんが、ごく少数だろう。
111:デフォルトの名無しさん
06/05/28 00:47:29
オプションつければええやん
仕事でコード書くときは、普通レポジトリ中のロケール合わせて
ビルドオプションにもそれ入れておくでしょ？
まぁあの書き方からして>>106をしてるっぽいんだが・・・・
>>110
複雑でいらねっていわれてたのは、ポインタと演算子のオーバオードだという記憶だねぇ
それが、今度はとうとう . 演算子をオーバロードすることになるわけか・・・
112:デフォルトの名無しさん
06/05/28 01:26:57
Parameterized typeもいらないって言っていたヤツいたけど、総じて馬鹿だった。
113:デフォルトの名無しさん
06/05/28 01:46:46
演算子のオーバーロードまではいかないんじゃない？
Java 5がでたときのインタビューかなんかでも、演算子のオーバーロードは
Javaを複雑にするので入れたくない、とSunの誰かが答えてたはず（ソース見つからず）
プロパティを obj.prop = value で設定できるようになったとしても、それはオーバーロード
とは言わんと思うし（シンタックス・シュガーだよね）
Dolphinでオーバーロードをサポートするとか言う発表があったんだっけ？
114:デフォルトの名無しさん
06/05/28 03:11:55
>>99
Gosling自身が「いらない」と言っていたんだけど。Bill Joyは「parameterized typeがあればどんなにいいだろう」といってたけどな。
つか、ほんとに聞いたことないのか。それはいくらなんでも世界狭すぎだろ。
あれか、恥ずかしい過去はなかったことにしたがってる連中か。
EJBのときとかわんねーな。あれも推進派だった連中が今は「やっぱりEJB2は複雑だったよな、アノテーションマンセー」だもんな。自分たちがどれだけEJBを押し付けてきたのか忘れたらしい。
foreach文もそうだよな。foreach文なんていらね、Iteratorパターン最高といってたヤシばかりだったのにな。
ほんと恥ずかしい過去はなかったことにしたいらしい。
115:デフォルトの名無しさん
06/05/28 03:23:36
foreachは聞いた事ないけど
116:デフォルトの名無しさん
06/05/28 03:48:27
いやいくらなんでもEJB2が複雑じゃないなんて話は聞いたことがない。
EJB2じゃないけど、Strutsだって「あれは壮大なネタだろ」とか言ってたくらいで、全般的に
冗長なフレームワークは嫌われてたように思うが。
genericsでは何度か見たが、一方でMapがタイプセーフでないことに苦しめられたって
意見もあったわけで、バランスは取れてただろ。
Java言語をシンプルなままにしておきたいという希望は俺にもある。一方で、書くのが楽に
なって欲しいという希望もある。一人の中でもせめぎ合いがあるんだから、スレ内でどっちの
意見が出たって不思議には思わんがね。
117:デフォルトの名無しさん
06/05/28 03:56:09
>>96
ヒアドキュメントがあると、文脈自由文法じゃなくなってしまうからJavaCCとかのパーサージェネレータで作りにくくなるよ。
118:デフォルトの名無しさん
06/05/28 05:33:15
>>116
EJB2が複雑という意見はあった。しかし、それは一部の開発者のみ。EJBを推進する連中のほうがずっと多かった（理由は「それが標準だから」だとさ）。
Strutsだって同じだろ。雑誌記事みればわかるじゃん。どれもEJBマンセー、Strutsマンセー。
EJBやStrutsを明確に批判したのはRodやTateなどごく一部。日本じゃ皆無。
>>117
単純なヒアドキュメントは字句解析だけで実現できる。パーサはいじる必要ない。
つうかな、これだけ機能がごちゃごちゃ増えてるのに、ちょっと文法たすだけなのがなんで問題なんだ。
今のJavaはコンパイラ作るのがすごい面倒な言語になったけど、それは機能が増えたせいで構文解析よりあとが大変になったからだろ。
それにくらべたら、構文解析までなんて簡単。ヒアドキュメントの追加ぐらいわけない。
ほかにずっと大きな問題があるのを見ないふりして、「パーサジェネレータで作りにくくなる」なんてささいな問題をとりだすなよ。
119:デフォルトの名無しさん
06/05/28 06:11:10
>>118
少なくとも、ヒアドキュメントは「ずっと大きな問題」じゃないな。
120:デフォルトの名無しさん
06/05/28 06:38:50
>>118
つ URLﾘﾝｸ(mustang.dev.java.net)
時代は貴方を求めています。言い出しっぺの法則ってことでﾖﾛﾋﾟｸ
121:デフォルトの名無しさん
06/05/28 08:04:10
俺はforeachいらねーわ。
122:デフォルトの名無しさん
06/05/28 09:46:04
>>114
GoslingがGenericsをいらないと言っていたというのは、信じがたいのだが。ソース希望。
Java House MLのアーカイブやその他の場所で引用されていた過去のGoslingの発言を見る限りでは、
Genericsの導入には前向きだったように思える。
あと、世界狭すぎなのは自分の方なのかも、って考えは無いのかね。
123:デフォルトの名無しさん
06/05/28 09:53:24
>>118
Rubyにあるような、式を埋め込めるヒアドキュメントはパーザをいじる必要があるけどな。
実際のところ、ヒアドキュメントはあれば便利だろうし、使うだろうけど、そこまでこだわる
程の機能か？あと、そんなにヒアドキュメントが本当に欲しければ、こんなところで
ぐちぐち言ってるよりも公式に提案した方が良いかと。Genericsやその他の言語拡張だって、
要望が多かったから取り入れられたわけだし、ヒアドキュメントも場合によっては取り入れられる
こともあるかもしれん。
124:デフォルトの名無しさん
06/05/28 10:07:39
Goslingが否定的だったのは、
C++のtemplateの特殊化やC++,CLOSなどのgeneric functionだろ。
operator overloadはかなり初期から批判的。
Bill JoyとGoslingが"暴力沙汰"になりそうになったのは、
Billがgenericsはゆっくり考えることにして、generics抜きでJavaをshippingしようとしたから。
Goslingは、進行はJCP任せだけど、collectionのreliabilityを増すと積極的。
C/C++に対する大きなアドバンテージと考えているから。> reliability
URLﾘﾝｸ(www.gotw.ca)
125:デフォルトの名無しさん
06/05/28 10:24:43
>>124
本題からはずれるのだが、C++のgeneric function(=テンプレート関数のことか？)
とCLOSのそれ(=マルチメソッド)は全く意味合いが異なるのでは。前者は静的に
呼び出しが決定され、後者は動的に呼び出しが決定されるので。
126:デフォルトの名無しさん
06/05/28 10:44:44
性的か童的か違うと「全く意味合いが異なる」のか?
「関数テンプレート」が正式名称な。C++03で間違っている部分も修正。
127:デフォルトの名無しさん
06/05/28 10:51:28
>>126
全くというと言いすぎだったかもしれんが、少なくとも意味が異なるのは事実。
Javaのメソッド **オーバーロード** とメソッド **オーバーライド** が異なるのと同じ。
関数テンプレートが正式名称というのは、知らんかった。すまん。
128:デフォルトの名無しさん
06/05/28 10:56:49
>>124は、わざわざ"generic function"って書いているんだから、
クラスに属さない多相型の関数のことを言っているのは自明だよ。
性的なw特殊化はわざわざ別に書いているし。
129:デフォルトの名無しさん
06/05/28 12:10:38
>>128
言いたいことがよくわからないのだが、C++には関数テンプレートとは
違う、"generic function"があって、それは、CLOSのように、実行時に
オブジェクトの型に応じて、動的にディスパッチしてくれるのか？
130:デフォルトの名無しさん
06/05/28 12:49:01
"generic function"をCLOSの意味に制限して、
意味不明って言っても仕方ないじゃないの?
一般名詞としての"generic function"は、C++のWGでも出ているよ。
例えば、URLﾘﾝｸ(www.research.att.com)
generic programmingで使うparametric polymorphismを持った関数が"generic function"。
知らないのはよっぽどうとい人だと思われ。
131:デフォルトの名無しさん
06/05/28 18:45:57
>>130
いや、"generic function"をCLOSの意味に制限したいわけ
じゃなくて、CLOSのそれとC++のそれは意味が異なる機能なのに、
124が
> C++,CLOSなどのgeneric function
と、C++とCLOSのgeneric functionが同じ機能かのように言っていたので、
つっこんだだけ。
132:デフォルトの名無しさん
06/05/28 22:01:40
>>123
ヒアドキュメントはあくまで例のひとつ。
「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎてうざいというのが主張内容。
JCPに提案しろとかポイントはずれてる。
133:デフォルトの名無しさん
06/05/28 22:29:35
>>131
> C++とCLOSのgeneric functionが同じ機能かのように言っていたので、
FUDかよw
134:133
06/05/28 22:52:36
お口直しに、
URLﾘﾝｸ(www.osl.iu.edu)
結局propertyは>>86の言うように、JSR245なの?
135:デフォルトの名無しさん
06/05/28 23:22:33
>>133
132だが、いい加減しつこいかもしれんが、どの辺がFUDなんだ？
136:デフォルトの名無しさん
06/05/28 23:25:08
>>135
間違えた。「132だが」は、「131だが」ね。
137:デフォルトの名無しさん
06/05/29 00:35:52
>>132
確かにポイントがずれてたかもしれん。
でも、結局、
> 「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎて
というのは、そんなに居るかなあとしか自分は思えない。あなたの
周りはそういう人ばっかりだったのかもしれんが、全体として
どうだったかというのは、ソースが無い以上、わからんし。
138:デフォルトの名無しさん
06/05/29 08:50:44
えーい、IDが無い板でそういう話題はやめーい。
技術の話でぶつかるならともかく！！！！
139:デフォルトの名無しさん
06/05/29 08:59:23
まあ、ヒアドキュメントは実装されても意見を180度変えるJava屋は少ないだろうな。
いらね。
140:デフォルトの名無しさん
06/05/29 09:10:29
XMLで出来るんだから、プレインテキストはいらんだろ。
141:デフォルトの名無しさん
06/05/29 12:41:52
>>134
JSR 245のexpression languageのところだけ、
つまり JSR-000245 JavaServer Pages 2.1 FR から抜き出された
JavaServer Pages 2.1 Expression Language Specification
だけ入るんじゃないのかな。property関係のところは。
1.6 Operator [] and .
The EL follows ECMAScript in unifying the treatment of the . and [] opeartors.
expr-a.idenfitifer-b is equivalent to expr-a["identifier-b"]; this is, the
indentifier identifier-b is used to construct a literal whose value is
the identififer, and then [] operator is used with that value.
(以下、式を評価する時のルール;略)
java.elのELResolver.getValue()辺りのインターフェースは
どうなるのか知らないが。もともとJSPのproperty用だからさ。
142:デフォルトの名無しさん
06/05/29 16:53:15
>>137
まさに、すぐ下にいるじゃん。>>139,140
今まで幾度となく同じことが繰り返されてきたし、これからもおんなじ。
143:デフォルトの名無しさん
06/05/29 16:58:39
つまり、>>43 がXMLリテラルがあればヒアドキュメントいらね、って言い出すと予言してるわけね。
144:デフォルトの名無しさん
06/05/29 17:34:37
ヒアドキュメントはもう話題としてはいいだろ。つまんねえし。
145:デフォルトの名無しさん
06/05/29 17:49:01
>>142
ヒアドキュメントなど、間違いなく不要。
146:デフォルトの名無しさん
06/05/29 23:48:08
あってもなくてもどうでもいいや。
自分ならヒアドキュメントで書きたくなるような文字列はコードと分離するけど。
147:デフォルトの名無しさん
06/05/30 01:46:32
まあつまりさ、genericsにせよヒアドキュメントにせよ、あれば使うし無ければ
今を受け入れるか、Javaを使わないしかないだろ。
おれはヘタレなのでMapに想定していないオブジェクトをつっこんじゃって、
キャストで落ちるなんてことをよくやってたからGenericsはすごくありがたい
けど、なけりゃないで、無いんだからどうしようもないから受け入れてただけ。
Genericsがないからまともなコードが書けません、なんて仕事では言えない
んだし。
148:デフォルトの名無しさん
06/05/30 02:42:09
いや、ヒアドキュメントは、あっても使う機会がない。
149:デフォルトの名無しさん
06/05/30 05:26:34
Ruby並にいろいろできるなら欲しいな、便利だし
150:デフォルトの名無しさん
06/05/30 06:57:54
スクリプト言語と比較されてもなあ…
ま、俺も>>146と同じでどっちでもいいや。どうせ使わないだけだし。
151:デフォルトの名無しさん
06/05/30 09:27:59
つうか、Ruby並にいろいろやりたいならJRuby使えばいいだけじゃん。
152:デフォルトの名無しさん
06/05/30 09:31:37
時々でいいのでGroovyのことも思い出してあげてください。。。
153:デフォルトの名無しさん
06/05/30 09:32:36
あ、Groovyってヒアドキュメントなかったかも....orz
154:デフォルトの名無しさん
06/05/30 09:34:55
>>147
List<Map<String,Object>>とかだとListとだけかかれるとソース追わないと中身確認できないのはきつい
ドキュメントでしっかり書いてくれるところならいいがListとだけかいているとぶち殺したくなる
もう1.4時代にはもどれんよな
155:デフォルトの名無しさん
06/05/30 09:48:47
>>153
Groovyには、式を埋め込める複数行文字列リテラルがあるよ
こんな感じ
def i = 100
println """
Hello ${i}
"""
これをヒアドキュメントと言っていいかは正直わからんの
だが、機能的には、文字列の終端となる記号を自由に指定
できないことを除いて、ほぼ同等だと思う
156:デフォルトの名無しさん
06/05/30 15:45:10
ヒアドキュメントは*絶対*に入れて欲しくない
こんなもの、保守やデバグを考えるとぞっとする
チームで禁止しても絶対使う奴が出てくるから嫌だ
157:デフォルトの名無しさん
06/05/30 16:54:31
どうせコンパイルして逆コンパイルしたら普通の文字列リテラルになるから問題なし。
158:デフォルトの名無しさん
06/05/30 17:55:57
ヒアドキュメントいれただけで保守やデバッグができなくなる>>156のレベルに乾杯
159:デフォルトの名無しさん
06/05/30 18:06:25
まぁお行儀の悪いプログラムを推奨してるかんじだしあまりいいものではないな
160:デフォルトの名無しさん
06/05/30 20:21:24
コンパイラ機能とあわせて使うと意外と便利かもよ
てかコンパイラ機能ってクラスキャッシュ直ぐ満杯になる欠点とかないの？
161:デフォルトの名無しさん
06/05/30 23:03:08
>>160
そんなことされると、さらにgkbr
162:デフォルトの名無しさん
06/06/02 02:54:34
ヒアドキュメント入れるときの妥協点として
コンパイルオプションでヒアドキュ封じができるようになればちょうどいい感じで導入できないかね？
プロジェクトで使う人もこまんないんじゃない？
163:デフォルトの名無しさん
06/06/02 07:44:25
そういう問題じゃない。
というかそこまでして導入するもんでもない。
164:デフォルトの名無しさん
06/06/02 17:03:39
プロパティは、
言語として加わるのか、
XML対応としてXMLの属性にgetValue/setValueするAPIがJDKに加わるのかどっち?
関連JSRは、
JSR 227: A Standard Data Binding & Data Access Facility for J2EE(TM)
JSR 245: JavaServer(TM) Pages 2.1
JSR 252: JavaServer Faces 1.2
JSR 295: Beans Binding
あたり? Expression Language周辺
165:デフォルトの名無しさん
06/06/03 22:35:13
>>40
なんだからPerlの q!文字列!やPHPの'文字列\n$変数'と'文字列$変数'との
違いを表してるブツみたいだな。
PHP的なものならまだしもPerlのq!文字列!みたいな
混乱するブツになるのは避けてもらいたいところだよな。
ダブルクォーテーションが無いだなんて、
あれ使う前に何か宣言でもするのかな
166:デフォルトの名無しさん
06/06/03 22:37:29
>>46-47
そのまんま@Propertyアノテーションとして使えばいいやんか
167:デフォルトの名無しさん
06/06/03 22:39:21
>>48
C#みたいな表向きは set/getと書くだけでプロパティが使えるが
実際には内部ではプロパティ変数名がたとえばtest のとき実際にはGet_test(), Set_test()
というメソッドが定義されているとコンパイラに解釈されるという奴でどうにかなるんだろう。
ただし、このときGet_test(), Set_test()という名前のメソッドを定義するとC#ではエラーになるが。
168:デフォルトの名無しさん
06/06/04 01:52:45
>>167
そういう暗黙の定義が適用されるのは、
対XMLデータとか、シリアライゼーションとか、
定義をクラスライブラリ側が持っているケースでしょ?
それは既にBeansやServer PagesのELであるよね。
JavaDocのtagもpropertyが増えてる。
Dolphinのは、言語がproperty採用するって事なんじゃないのかな?
要するに、setter/getterはプログラマが記述して、
フィールド参照がsetter/getterに置き換わるヤツ。
169:デフォルトの名無しさん
06/06/04 01:56:45
>>96
遅レスながら激しく同意。ほんとJavaには呆れる。
170:デフォルトの名無しさん
06/06/04 02:11:29
>>165
> >>40
> PHP的なものならまだしもPerlのq!文字列!みたいな
> 混乱するブツになるのは避けてもらいたいところだよな。
例えばの話だが
"<p id=\"hoge\" onmouseover=\"hige('fuga')\" class=\"hage\">";
q{<p id="hoge" onmouseover="hige('fuga')" class="hage">};
どっちが見易いかっつう話だ。
q{}とは違うが正規表現の場合も考えてみ。JavaよりC#の@の方がまだマシだろうに。
171:デフォルトの名無しさん
06/06/04 10:21:22
>>75
そんな書き方するのがいやだったら
インクリメントできるメソッドを定義したほうがいいんじゃないのか？
172:デフォルトの名無しさん
06/06/04 10:24:18
>>96
いっておくがC++のtemplateとJavaのgenericsとはまったく別もんだよ。
比較サイトでも似て非なるものであると書いてある。
よって全然手のひらを返したことにはならんよ
173:デフォルトの名無しさん
06/06/04 10:25:14
>>96
ヒアドキュメントは下手な奴が使うとソースコードを読みにくくするからな。
Perl厨が書いたコードみたいにな。
174:デフォルトの名無しさん
06/06/04 10:27:07
>>172
C++ templateの重要な特性である、コンパイル時プログラミング
ができるという機能をJava genericsは持って無いし、別物と言って
良いだろうね。
175:デフォルトの名無しさん
06/06/04 10:27:51
>>114
だからC++のテンプレートはJavaのGenericsと全く
同じではないと何度言ったら(ry
だからあれほど言ったものを
176:デフォルトの名無しさん
06/06/04 10:28:25
しかも今のJavaにも"foreach"なんてキーワード出て来ないし
177:デフォルトの名無しさん
06/06/04 10:30:19
>>122
>>114はGoslingが「C++Templateの機能すべてはいらない」と
言ったのを勝手に「Genericsはいらない」と誤認しているだけなんだよ。
恥ずかしい奴だから
178:デフォルトの名無しさん
06/06/04 10:32:21
for (型 変数名 : コレクション) 文
いらねーよ、こんなの。
179:デフォルトの名無しさん
06/06/04 10:34:18
>>139
ま、Perlそっくりそのままのヒアドキュメントが実装されたら
あれだな。
XMLのCDATAセクションみたいなのがJavaソースコードに紛れるのかね
だとしたらJavaソースコードがまるっきりXML文書の一部になる？
180:デフォルトの名無しさん
06/06/04 10:38:02
>>178
お前らがforeachが無いんですけど(^^;;とか騒ぐから
181:デフォルトの名無しさん
06/06/04 10:38:10
>>178
便利だよ
182:デフォルトの名無しさん
06/06/04 10:38:44
>>170
そんなことをするんだったら別ファイルに書くか
JSPやカスタムタブライブラリやJSFやApache Struts
やJakarta Velocityを使うがな
183:デフォルトの名無しさん
06/06/04 10:40:42
>>174
もっと決定的な違いがあるよ。
C++厨がJava Genericsではこれができないと
愚痴を零している数々の機能。
多重継承ができないからといってブツブツ文句をいうＣ++厨が
いるようにJava GenericsがC++Templateとはあまりにも
違うことに文句をつけている変な奴がまだまだいるのさ
184:デフォルトの名無しさん
06/06/04 10:48:11
>>182
JSFやApache Strutsはヒアドッキュメントの代替にならない件
185:デフォルトの名無しさん
06/06/04 10:48:59
昔、ほんとにいらないのか、パクリを認めたくないのか
「いらねーよ、こんなの。」と言ってたものが
今までも、そしてこれからも追加されていくわけやね。
186:デフォルトの名無しさん
06/06/04 10:55:38
まあ、ヒアドキュメントが追加されることはないから心配するな。
187:デフォルトの名無しさん
06/06/04 10:55:58
そら便利ならそうなるわな。しないほうが馬鹿と言われる。
188:デフォルトの名無しさん
06/06/04 10:59:16
プロパティに関してはみんな欲しいと言ってたわけだしね。
XMLリテラルはいらねーともいるとも言ってない晴天の霹靂
189:デフォルトの名無しさん
06/06/04 11:00:13
J2EE方面の人の声が大きくなってきているね。
190:デフォルトの名無しさん
06/06/04 11:01:03
>>183
> Java GenericsがC++Templateとはあまりにも違うことに文句をつけている変な奴
ただ、Java Genericsは、Java仮想マシンの互換性を保つために、いろいろと
面倒な仕様になっているので、文句を付けられても仕方無いと思える部分もある。
特にC#のGenericsと比べると、その部分が際立つ。
191:デフォルトの名無しさん
06/06/04 11:01:35
金をだすのはエンタープライズ方面
192:デフォルトの名無しさん
06/06/04 11:05:46
いいかげんジョイスティックPureＪａｖａでさぽーとしてくれねぇかなぁ
デスクトップに目を向けています！なんてよくいえたものだ＞5.0
1.4のほうがクライアントサイドで大幅によくなってたが、5.0ほとんどかわってねーし
6もほとんどかわってねーな
グループレイアウトが標準になるくらいか
193:デフォルトの名無しさん
06/06/04 11:06:46
ところでなんでこの時間だけいきなりレスふえたんだ？
しかも亀が多い
194:デフォルトの名無しさん
06/06/04 12:02:18
>>178
けっこうスッキリするけどね
195:デフォルトの名無しさん
06/06/04 12:03:07
>>193
日曜だけ見る奴とかいるんでね？
196:デフォルトの名無しさん
06/06/04 12:03:54
>>180
foreachはないけどfor(;;)やfor(;)はあるってことで
GenericsはあるけどC++Template相当のものはすべては無いってことで
「否定していた癖にJavaにforeachやGenericsが出た」と主張した奴は
馬鹿って事で
197:デフォルトの名無しさん
06/06/04 12:04:55
>>194
で、処理中にインデックスがいると分かり、for (int i = 0; i <
に書き直したり。これがアホくさい。言語レベルで今何番目か
分かるようにしてほしい。
198:デフォルトの名無しさん
06/06/04 12:05:48
>>184
それでも今Perl臭いヒアドキュメントの必要性は
感じないな。
JSFやStrutsがヒアドキュメント代わりになるというより、
>>170のようなHTMLコードをいちいちJavaコードの中に
埋め込むというくだらないことをしなくて済むという観点から
>>184の主張が現れている。
199:デフォルトの名無しさん
06/06/04 12:08:02
>>185
追加されるっていっても過去の言語にあるものとは
違うモノだから。
enumだってそうだし。
C/C++のenumはJavaのenumとは似て非なるものであって
Genericsが登場したからこそ実現できたものであって
C/C++のenumとくらべたら断然機能的で優れている。
よってC/C++のenumとJavaのenumとはまったく別のものである。
だから、かつてJavaにeumがいらないという発言があったのは
「Javaの新しいenumが要らない」というのではなく
「C/C++で実装されている仕様のenumが要らない」ということだったのだ。
200:デフォルトの名無しさん
06/06/04 12:08:33
>>188
みんなって誰？
あれの需要はそんなにあるとは思えないな
201:デフォルトの名無しさん
06/06/04 12:09:54
>>192
ハードウェア方面にまでPureJavaをサポートするのは
まだまだ先だろ。
JiniやらJava Communication API をどうにかしないと
202:デフォルトの名無しさん
06/06/04 12:10:26
>>195
それはありうる。
>>193 >>195
というか偶然ともいえるだろう。
203:デフォルトの名無しさん
06/06/04 12:11:43
>>197
それはIteratorの意味が無いとちゃうか？
何番目を知りたいかだなんて使い方が間違ってると思うぞ。
アルゴリズムや作りたいものによるが、
コレクションの分割とか考えるといいかと
204:デフォルトの名無しさん
06/06/04 12:17:10
そもそもコレクションの機能にランダムアクセスなんてないだろ
interface RandomAccessとinterface Collectionは別の機能だ
205:デフォルトの名無しさん
06/06/04 12:18:04
>>203
間違ってるか？ というか、拡張 for 使いまくった？
えーと、そうだ、おまい今まで組んだものはループは全部 Iterator か？
例えば、画面に行No出力する場合はどうする？
JSTL とかテンプレート言語が無い場合ね。
206:デフォルトの名無しさん
06/06/04 12:20:21
>>197
俺もインデックスが必要になるのがあとで必要になって書き直したりするよ
でも、イテレータパターンであることを言語的に保証するものだからありでは？
インデックスだと中身まで見ないと流れが把握できない
>>201
キーボードやマウスと同じ一般的な入力インターフェースなんだが
ついでにMSXのようにキーボードもジョイスティック0番とかでつかえるようにしておけば
コードを分ける必要もなくていいのだが
同人ソフトとかでJava製の物がほとんどない原因のひとつでは？
フルスクリーン等は1.4でサポート、じゃヴぁSoundは1.3でサポートされやっと使い物になってきたが
インターフェースがないのではね
1.1時代＋JNIでなんでもできるということはなかったはずだし
JNIも万能ではない（スタックサイズ制限で引っかかる）からね
VM自体のリコンパイルが必要になるし、さすがにそれは現実的ではないだろう
207:デフォルトの名無しさん
06/06/04 12:25:27
> 同人ソフトとかで
を例に示されてもワカラネw
分かるのが普通か？
208:デフォルトの名無しさん
06/06/04 12:26:28
「デスクトップ分野にも力を入れています」は口だけ
209:デフォルトの名無しさん
06/06/04 12:28:51
そんな大した手間じゃないと思うけどな＜パッド・スティック対応
PadListenerみたいな標準インタフェース用意して、メーカー側が対応するSPIをサイトに置いとけばいいじゃん
210:デフォルトの名無しさん
06/06/04 12:33:21
>>203
> 何番目を知りたいかだなんて使い方が間違ってると思うぞ。
それは言い過ぎだろw
けどループ構造は代えずにカウンタ一つ用意すればいいだけだよな。
211:デフォルトの名無しさん
06/06/04 12:34:44
>>209
URLﾘﾝｸ(sourceforge.net) にあるが、
標準でサポートしろって事でしょ。
けどジョイスティックはそもそもインターフェースが統一されているとは言いがたいし…
212:デフォルトの名無しさん
06/06/04 12:38:53
>>210
カウンタを用意するとループのスコープの外に変数を作ることになる。
なんかいや。
213:デフォルトの名無しさん
06/06/04 12:43:47
カウンタ用意したらイテレータパターンの意味ないだろ
何番目か意識することなく取り出すのが目的なんだから
カウンタ使いたければふつうにfor( ; ; )すればいいだけ
>>211
2軸32ボタンまではOSレベルで標準サポートされてるはずだ
214:デフォルトの名無しさん
06/06/04 12:46:49
だから、Iterator パターンでも、必要であれば、カウンタが
とれればいい。freemarker のように。
215:デフォルトの名無しさん
06/06/04 12:50:12
Iteratorのコード書くよりは拡張forの方がはるかに楽な件
Iteratorのコードの場合、カウンターが必要なら拡張for使わなくてもIteratorかカウンタ変数かどちらかがスコープの外に出る件
216:デフォルトの名無しさん
06/06/04 12:54:04
ジョイスティックが「デスクトップがんばる」の範囲に入ってなくてもほとんどの人が困らない件
217:デフォルトの名無しさん
06/06/04 13:01:36
>>215
ここで言ってるIteratorは拡張Forのことだという件
218:デフォルトの名無しさん
06/06/04 13:07:26
>>213
>>204の言っている意味も理解できないのかよ。
219:デフォルトの名無しさん
06/06/04 13:13:25
>>206
> >>201
> キーボードやマウスと同じ一般的な入力インターフェースなんだが
> ついでにMSXのようにキーボードもジョイスティック0番とかでつかえるようにしておけば
> コードを分ける必要もなくていいのだが
Adapterパターンでうまいことラッパークラス作れよw
220:デフォルトの名無しさん
06/06/04 14:12:33
>>216
ほとんど外の人がデスクトップ普及熱の根幹である件
221:デフォルトの名無しさん
06/06/04 14:22:25
>>219
みんなラッパつくってるだろ
それが面倒だということだろ
222:デフォルトの名無しさん
06/06/04 14:24:39
というかJ2SE5.0でデスクトップ改良部分ってなんかあったっけ？
1.4は明らかに今後がんばるんだなぁという光が見えたわけだが
223:デフォルトの名無しさん
06/06/04 14:39:46
ラッパならどこかでダウソできたような気がする
224:デフォルトの名無しさん
06/06/04 14:41:34
5.0は思いつかない。
6はピュアGUIやスクリプトなど一応の発展はある。
225:デフォルトの名無しさん
06/06/04 16:28:04
Google Web Toolkitのような使われ方も次世代Javaか？
226:デフォルトの名無しさん
06/06/04 17:26:49
>>222
みんなOceanに腰を抜かしたはず
あのセンスに。
たぶん、アレで識者は「これは俺が何とかせねば」と奮起したと思われる。
インデックスが必要ということはカウンターが必要であるということで
コレクションを操作するという事とは別の要素が必要になったということ
繰り返し処理と、カウンタを使うという意味を切り分ける意味で
俺は別にカウンタを用意している。
カウンタも０からスタートさせたい場合や、1からスタートさせたい場合など色々。
もし、繰り返し処理で使うなら、拡張機能をさらに入れたい。それで
・カウンタの初期値
・カウンタのステップ
を決めたいのだが、そうなるとforeachタイプforにさらなる
文法拡張が必要になるなぁ。
for( Object i : list : 0 : 2 ){
}
あ、イテレーションのコンテキストにアクセスするのに文法も必要か・・・
コレは一筋縄じゃいかんねぇ
227:デフォルトの名無しさん
06/06/04 18:13:09
>>226
それだよ、それ。そういう拡張が欲しい。
スコープもループ内だしな。
228:デフォルトの名無しさん
06/06/04 18:29:05
>>226
もういっそのこと、Schemeのようなマクロを導入して、
そういう拡張は自分で定義してね、とするとか
まあ実際にはあり得ないだろうけど
229:デフォルトの名無しさん
06/06/04 19:02:34
>>228
そういうのを要求する人はjavaの拡張を待つまでもなく、もうm4とかの
マクロプロセッサを使ってるんじゃないのかね。
230:デフォルトの名無しさん
06/06/04 19:07:58
Java のスレの中では初心者質問スレを除き、このスレが一番伸びている件について。
231:デフォルトの名無しさん
06/06/04 19:12:50
>>226
別に、普通に0ベースか1ベースのインデックスさえ手に入れば、
n + m * indexで、nまたはn+mからスタートしてステップmの
カウンタが手に入るじゃないの。
>>228
この程度ならマクロなんて必要なくて、レキシカルクロージャが
導入されていれば、簡単につくれるんだよねえ。
232:デフォルトの名無しさん
06/06/04 19:38:56
JavaSE6も近いからな
関係ないか
233:デフォルトの名無しさん
06/06/04 19:47:44
中途半端な知識で参加できるからだと思われ
234:デフォルトの名無しさん
06/06/04 20:25:07
>>226
いらねー
くだらねー
235:デフォルトの名無しさん
06/06/04 20:39:03
Jakarta Velocityの変数$velocityCountみたいなのがあれば
いいんでね？
236:デフォルトの名無しさん
06/06/04 21:23:13
いらん
237:デフォルトの名無しさん
06/06/04 21:30:28
普通はいらんね
238:デフォルトの名無しさん
06/06/04 21:53:15
>>231
レキシカルクロージャがあれば、その程度なら簡単にできる
というのはその通りだが、クロージャだけでは簡単にできない
拡張もある。で、諸々の拡張に対する提案全部を取り入れてたら
きりが無いので、マクロを定義する仕組みだけ用意して、あとは
ユーザが勝手にマクロを作ってねとしたらどうか？というのが228
で言いたかったこと。まあ、マクロは濫用される危険性が大きい
機能でもあるので、Javaのような言語に実際に入ることは無いだろうけど。
239:デフォルトの名無しさん
06/06/04 21:53:18
Freemarker の変数 $～_index みたいなのがあれば
いいんでね？
240:デフォルトの名無しさん
06/06/04 21:56:02
イラネーよ、そんな糞機能
241:デフォルトの名無しさん
06/06/04 22:16:57
ロードまぷ
URLﾘﾝｸ(roumen.name)
242:デフォルトの名無しさん
06/06/04 22:32:28
SPECJBB2000なんて字樹上にそぐわないベンチ使ってるのが怪しい
2005なんでつかわないのだ
1.2.2でノーマライズとかいてるのもあやしい
1.3.1とかなり違うはずなのだが
243:デフォルトの名無しさん
06/06/04 23:40:00
>>213
>カウンタ用意したらイテレータパターンの意味ないだろ
>何番目か意識することなく取り出すのが目的なんだから
>
>カウンタ使いたければふつうにfor( ; ; )すればいいだけ
これはちがうだろ。Iteratorは、データ構造に依存せずに繰り返しのためのインターフェースを提供することが目的。
Iteratorが考えだされるまでは、ListやArrayやTreeといったデータ構造ごとに、繰り返しの操作が異なっていたし、それが当たり前だった。
それがIteratorによって、どれでも同じインターフェースで繰り返しが行えるようになった。
Iteratorの目的は「繰り返し」の抽象化であり、そのこととカウンタとはぜんぜん別の問題。
ListやTreeに対してはIteratorとカウンタの両方を使うべきであり、for(int i=0; i<count; i++)とかするのはバカ。
244:デフォルトの名無しさん
06/06/04 23:43:40
>>243
カウンタ用変数を外側に用意すれば?
もちろん｛ ｝で一段スタック入れてスコープ狭める
245:デフォルトの名無しさん
06/06/04 23:51:24
>>243
Iterator 大好きなんだな。
別にそこまで無理してデザパタ使わなくてもいいよw
246:デフォルトの名無しさん
06/06/05 00:10:39
ArrayListから配列取り出して
//こっちのほうがわかりやすいから
とコメントしてforで回してるソースを見たときは声出してﾜﾛﾀ
247:デフォルトの名無しさん
06/06/05 00:15:45
>>245は馬鹿だね
248:デフォルトの名無しさん
06/06/05 00:21:12
デザパタ厨的には、IndexableIteratorというデコレータを作るのかな。
249:デフォルトの名無しさん
06/06/05 00:35:13
Iterator パターンは内部を意識することなく順次取出しするのが目的であって
何番目とかの処理を意識させるのは必要ないからな
あなたは何番目ですか？がロジックで必要なら自前で用意するだけ
今までのfor構文でイテレータ使ってたのと同じでこれはかわってないだろ
250:デフォルトの名無しさん
06/06/05 00:38:23
>>245
必死だな
251:デフォルトの名無しさん
06/06/05 02:01:46
>245
ﾜﾛｼｭ
252:デフォルトの名無しさん
06/06/05 02:39:44
>>248
似たようなもんがJakarta Commons Collectionsになかったか？
253:デフォルトの名無しさん
06/06/05 02:52:50
Map用のfor文が欲しい
for(String key,String value : map) { 文 }
みたいな
254:デフォルトの名無しさん
06/06/05 03:02:43
Entryでいいじゃん
for(Map.Entry entry : map.entrySet() )
255:デフォルトの名無しさん
06/06/05 09:42:15
Iterator → デザインパターンってヤツは誤解しているぞ。
IteratorはCLUで70年代からある。
256:デフォルトの名無しさん
06/06/05 11:46:58
>>253
MapをIteratorに変換するか
MapとListが一緒になった、Jakarta Commons Collectionsにある
あのクラスを使えば医院ジャマイカ？
257:デフォルトの名無しさん
06/06/05 11:47:34
>>255
GoFの一つにIteratorパターンがあるからね。
デザインパターンとしてのIteratorは後から出たモノだとおもう
258:デフォルトの名無しさん
06/06/05 11:51:11
>>254
それだと、Entryからkeyとvalueを取り出さなきゃいけないじゃん。
253だとその手間が省ける。それが大事。
259:デフォルトの名無しさん
06/06/05 12:04:53
そこまで大事か？
260:デフォルトの名無しさん
06/06/05 12:40:00
>>259
まあ、あれば便利かもしれんが、そこまで重要な機能ではないわな。
foreachに比べると、使う機会も少ないだろうし。
261:デフォルトの名無しさん
06/06/05 19:25:26
つうか、>>253くらいのことは簡単に実装できるんだから、拡張for文を導入するときに
いっしょに導入してくれればよかったんだよ。
そのくらい、ふつうに気がつくだろ。なんで直接Mapが使えないように限定するのかさっぱりわからん。
262:デフォルトの名無しさん
06/06/05 19:40:33
>>261
そんなこと言ってると
あれも入れろこれも入れろで収拾付かなくなるから。
263:デフォルトの名無しさん
06/06/05 19:49:14
Entry回せばいいじゃん、極一部のクラスのためだけにそんな馬鹿な仕様取り入れるかよ
Collectionはデータ構造に関するJavaの主要フレームワークの根元だから特別視されるだけだ
264:デフォルトの名無しさん
06/06/05 20:08:49
try-open-finally-closeも特別扱いしてほしい。
265:デフォルトの名無しさん
06/06/05 20:13:57
try-finallyデストラクタを強制するためにも
openとcloseは例外を投げる設計にしたほうがいいんだよな
>>264
どんな感じの？
266:デフォルトの名無しさん
06/06/05 20:40:25
>>262
そのくせプロパティやらXML直書きやらは導入されるんだ。
そっちのほうが収拾つかんわ。
267:デフォルトの名無しさん
06/06/05 20:44:59
>>266
Map の foreach なんて generics+プロパティ導入で e.key と e.value で済むんだから
わざわざ入れなくてもいいだろ。
268:デフォルトの名無しさん
06/06/05 22:08:03
クロージャが出来るそうだから、
foreach(aMap, クロージャ);
でいいよ。
269:デフォルトの名無しさん
06/06/06 01:47:50
クロージャは導入必至。
オヤジJavaプログラマの「クロージャは苦労じゃ」のネタは既に
あるものとして色々なバリエーションが考えられてるからです。
どんなものでもイイが、上のネタを生かすために簡単なものであっては困る事だけは確かだ。
270:デフォルトの名無しさん
06/06/06 02:25:33
クロージャの正しい概念ってどんなの？
ECMAScriptだとthis参照を遅延生成メソッド内に埋め込むやり方で使ってるよね
でもJavaのthisってコンテキスト参照じゃなくてインスタンス参照でしょ？
271:デフォルトの名無しさん
06/06/06 02:44:45
XMLリテラルがどういう利点があるかわからないんだけど。
272:デフォルトの名無しさん
06/06/06 03:11:42
>>271
構造を持ったデータを簡単に作れることじゃないの？
今までせこせこ、ＬｉｓｔとかＭａｐとか組み合わせてたような奴
273:デフォルトの名無しさん
06/06/06 03:28:52
アノテーションにxmlリテラルが使えると、外部xmlファイルが必要なくなるのは嬉しいか嬉しくないか微妙。
274:デフォルトの名無しさん
06/06/06 08:35:14
>>270
URLﾘﾝｸ(foldoc.org)
の1かな。
Javaに実装するなら、new Callable() { ... } あたりを楽に書ける
シンタックスシュガーとして実装がいいんじゃない。
つまり、ローカル変数はfinalなもののみアクセスできる。
>>36 のようなことがやりたければ、
final int[] sum = { 0 }
で切り抜ける。
275:デフォルトの名無しさん
06/06/06 20:11:40
使い勝手が悪そう
276:デフォルトの名無しさん
06/06/07 04:21:46
ヒアドキュメントすら否定するのにXMLリテラルは受け入れるJava厨乙
277:デフォルトの名無しさん
06/06/07 05:45:45
>>276
受け入れてないよ。だからヒアドキュメント否定するんだろ。
278:デフォルトの名無しさん
06/06/07 05:49:46
とか言いながら、いざ実装されるとマンセーするのがいつものパターン。
279:デフォルトの名無しさん
06/06/07 07:45:12
ヒアドキュメントはイラン。
ところで、クロージャーって、単なるシンタックスシュガーじゃなくて、スクリプト言語用のバイトコード拡張を利用する構文じゃないのかな。
280:デフォルトの名無しさん
06/06/07 11:05:11
>>279
それは激しい・・・
ヒアドキュメントと変わらんじゃないですか
スクリプト言語のシンタックスがわからない以上・・・・
281:デフォルトの名無しさん
06/06/07 11:13:26
>>279
それはまず無い。スクリプト言語用のバイトコード拡張(invokedynamicだったか)は、
クロージャの実装に使えるようなものじゃない。クロージャが単なる匿名クラスの
シンタックスシュガーになるんじゃないだろうというのは同意だが、クロージャは、
別にバイトコードを拡張しなくても、既存のコードの互換性を保った形で追加できるはず。
282:デフォルトの名無しさん
06/06/07 11:41:58
invokedynamic(JSR292)は、
そもそも動的メソッド呼び出しだけだから、
Funarg問題を解決してくれるようなもんじゃないしね。
# Hotswappingの方向で進んでいるからslot参照も付くんだろうが。> JSR292
どういう実装するかよりも、どういう仕様になるかの方が…
たぶん、inner anonymous classの参照しているlocal変数、実引数、
例外処理ハンドラ引数がfinalでなければいけないという制約が
closureの場合は外れるかどうか。
Inner anonymous classを使った実装になるのは確実でしょ?
後はsyntax sugerでしょうね。
Closure出来たら、コレクションも新しくしないとねw
283:デフォルトの名無しさん
06/06/07 11:45:10
>>280
三行とも意味がわからん…w
Groovyの文法は既に定義されているし
284:デフォルトの名無しさん
06/06/07 12:21:26
>>282
281だが、
> たぶん、inner anonymous classの参照しているlocal変数、実引数、
> 例外処理ハンドラ引数がfinalでなければいけないという制約が
> closureの場合は外れるかどうか。
外れると思うなあ。じゃなきゃ、セマンティクスとしては
今までとほとんど変わらないんだから、わざわざクロージャ
を追加するなんて言い方はしないでしょ。あと、細かいが
実引数は仮引数の間違いでは？
> Inner anonymous classを使った実装になるのは確実でしょ?
> 後はsyntax sugerでしょうね。
実装としては、Inner anonymous classを使うのに近いものに
なるだろうが、仕様としては単なるInner anonymous classの
シンタックスシュガーになるってことは無いと思う。
285:デフォルトの名無しさん
06/06/07 12:35:22
>>261
なにも考えずに下手に導入するとC#やC++の二の舞となるぞ。
どうしてもそういう機能が欲しければ
C++やC#で実装して貰うように頼むか自分で実装するという手もありだな
286:デフォルトの名無しさん
06/06/07 12:41:34
ああ、実引数の間違いね。
Closureを実装するにあたって、
JVMの仕様を変えるという話は出てきてないから、
ほとんどsyntax sugarみたいなもんなはずだけどね。
というかinner anonymous classがほとんどclosureみたいなもんだし。
finalが外れるとしても、primitive typeの扱いはどうするのか…
287:デフォルトの名無しさん
06/06/07 12:43:31
>>285
つーかクロージャができる今となっては>>268でいいでしょ。
拡張forは黒歴史だ。
288:デフォルトの名無しさん
06/06/07 12:51:02
>>286
JVMの仕様を変えないでも、「本物の」クロージャは実装できるよ。
あと、キャプチャされる変数がprimitive typeかどうかは、クロージャ
実装するにあたっては、特に関係無いはずだけど、何か問題ある？
289:デフォルトの名無しさん
06/06/07 13:10:14
outer classのslotは、
closureに埋め込んだouter class instansの
thisを介して参照すれば書き換え可能だけど、
引数はちょっと面倒じゃない? > primitive
Method内でclosureが使われる時、
first class closureが外に持ち運び出されれて使われる時、
複数のclosureからprimitive typeが参照される時の扱いなど。
まあコンパイラが頑張れない問題ではないけれど。
そういうprimitive typeは、
別のinner anonymous classでwrappingすればいいんだから。
290:デフォルトの名無しさん
06/06/07 13:38:10
ローカル変数も基本型だとスタックフレームにあるから、
オブジェクトでラップしとかないといけないよね。
外に持ち出して複数のクロージャから参照されるかもしれないから。
291:デフォルトの名無しさん
06/06/07 19:17:14
>>289
それは、クロージャからouter classのフィールドを参照しているか
outer scopeのローカル変数を参照するかによる違いであって、
primitive typeかどうかは関係無いのでは？クロージャから
outer scopeのローカル変数を参照可能で、かつ、クロージャから
その変数が変更可能なようにする場合、基本型かどうかに関わらず、
オブジェクトでラップする必要が生じると思うんだが。
292:デフォルトの名無しさん
06/06/07 19:54:33
>>283
あのースクリプト言語ってGroovyだけじゃないんですが・・・
スクリプト言語への対応って言語の定義はされてなくて、APIの定義なんですよ。
おそらくそこを勘違いされていますよね？
今あるスクリプト言語だけじゃなくて将来出てくる言語もこのAPIに沿ってライブラリを
用意すれば使えるっていうフレームワークです。
293:デフォルトの名無しさん
06/06/07 19:57:25
今までずっとコンパイル言語はデリゲート、スクリプトはクロージャって漠然と思ってたけど
もしかしてもっと高尚な概念だったのか？ｗ
294:デフォルトの名無しさん
06/06/07 20:04:53
スコープがどこにあるかで変わるような気もするが
デリゲートっていうのはクロージャーよりもっと大きな範囲を表すことばじゃないか？
295:デフォルトの名無しさん
06/06/07 20:05:00
>>293
別に高尚というほどのものではないが、ある言語がコンパイル言語かスクリプト言語
かどうかと(この区別の仕方も問題大有りだがそれは置いとく)、その言語がクロージャ
を持っているかどうかは全く関係が無いことは確か。あと、デリゲートってたぶんC#の
デリゲートのことを言ってると思うんだが、あれはMS用語であって、C#のあの機能に
対する用語としては全く一般的じゃない。
296:デフォルトの名無しさん
06/06/07 20:09:16
D言語もdelegateだろ？そのうち次世代標準になると思うが
297:デフォルトの名無しさん
06/06/07 20:30:15
>>296
逆に言えばC#,Dしか無いんだと思うが。しかも、時系列からして、D言語で
delegateって呼んでるのは、C#での呼称をまねたんだろう。次世代標準に
なるかは知らないけど、delegateはあまりセンスがいい機能だとは思えん。
298:デフォルトの名無しさん
06/06/07 21:55:27
delegateといえばそんな名のproxyを思い出すのはもうおじちゃん世代なんでしょうか・・・
299:デフォルトの名無しさん
06/06/07 22:47:03
>>291
outer scopeのローカル変数を参照している場合、
クロージャオブジェクトとは別のオブジェクトでさらにラップする必要があるでしょ。
複数のクロージャから共有される場合は必ず。
基本型じゃなければ、実はポインタが指しているわけだから、
複数のクロージャオブジェクトから共有するのは自然にできるけれど。
300:デフォルトの名無しさん
06/06/07 22:49:22
プログラミング言語で、"delegate"を最初に聞いたのは"actor"かな。
301:デフォルトの名無しさん
06/06/07 23:20:27
>>299
> outer scopeのローカル変数を参照している場合、
> クロージャオブジェクトとは別のオブジェクトでさらにラップする必要があるでしょ。
> 複数のクロージャから共有される場合は必ず。
これは特に異論を言ったつもりは無い。というか、クロージャのセマンティクスを
考えれば、至極当然だわな。
> 基本型じゃなければ、実はポインタが指しているわけだから、
> 複数のクロージャオブジェクトから共有するのは自然にできるけれど。
これはおかしい。クロージャから共有しているのは、ローカル変数その
ものであって、変数の値じゃないのだから、ローカル「変数」に対する
変更をクロージャ間で共有するためには、基本型じゃなくても
クロージャオブジェクトとは別のオブジェクトでラップする必要があるはず。
302:デフォルトの名無しさん
06/06/08 00:12:04
「これはおかしい」以降が分かりません。
ヒープに浮いているオブジェクトを共有していれば十分かと。
303:デフォルトの名無しさん
06/06/08 00:38:40
>>302
クロージャによって共有されるのは、参照型変数が指している先の
オブジェクトじゃなくて(もちろんオブジェクトも共有されるけど)、参照型変数
そのものなので、オブジェクトだけが共有されても変数そのものが共有されないと、
クロージャAで参照型変数aの指している先を変更した後(ここで、オブジェクトの
中身を書き換えるのではないことに注意)、別のクロージャBから同じ変数aを
参照したときに、クロージャAによって変更される前のaの参照先を指している、
というようなことになってしまう。
304:デフォルトの名無しさん
06/06/08 06:54:29
>>302
>>32 の
int sum = 0;
list.each(delegate(int i){
sum += i;
});
で、sum が java.lang.Integer、クロージャの中が
sum = new Integer(sum.intValue() + i);
だった場合に、オブジェクト共有じゃだめでしょ。
305:デフォルトの名無しさん
06/06/08 08:13:48
Javaなら「クロージャいらね、無名クラスで十分」でお願いします。
そしてクロージャが実装されたあかつきには「やはりクロージャは便利だ、すばらしい」でお願いします。
306:デフォルトの名無しさん
06/06/08 08:21:39
まぁ、使ってみなきゃわからない便利さってのもあるしな
307:デフォルトの名無しさん
06/06/08 09:15:16
>>305
さすがにクロージャに関しては、無名クラスで十分というのは
あり得ない気がする。特に無名クラスを制御構造の抽象化
(内部イテレータなど)に使うのは、冗長過ぎる。複数のメソッドを持っている
オブジェクトの場合は、無名クラスの方がいい場合もあるとは思うけど。
308:デフォルトの名無しさん
06/06/08 09:16:38
>>305
あいかわらず分析力のないｗｗｗ
309:デフォルトの名無しさん
06/06/08 12:16:34
>>308
別に分析なんてしてないんじゃない？
Java vs ○○系のスレで何度も起きていることを
そのまま書いただけでしょ。
310:デフォルトの名無しさん
06/06/08 13:29:23
は？ 意味がわかりませんな
あんたのいってることは
311:デフォルトの名無しさん
06/06/08 14:37:40
分からないならレスしなくていいよ。
もうちょっと勉強してからどうぞ。
312:デフォルトの名無しさん
06/06/08 14:39:51
くだらん煽りだ
313:デフォルトの名無しさん
06/06/08 14:40:54
>>312は>>310宛
314:デフォルトの名無しさん
06/06/09 03:16:58
★ネタは分かりやすく★
>>305 は
Javaユーザが、Generics導入前には「いらね」と言っていたのに
導入されたら「Genericsネ申」と褒め立てるJavaユーザをクロージャにも当てはめ
シニカルな笑いにしたネタ( ´ー｀)y-~~
>>308 は
それをむしろJavaユーザの立場から自嘲的に笑いにしたネタ
もしくは、単に>>305 の諧謔を理解せず笑ったﾉ(´д｀*) レス
>>309 は
それをJavaユーザに対する真っ向非難と受け止めた
瞬間湯沸かしレスヽ(`Д´)ﾉ
>>310
もう喧嘩と聞いちゃ黙っちゃいられない江戸っ子レス
(ﾟ∀ﾟ )三 三( ﾟ∀ﾟ)
>>311
それに便乗した野次馬
( ´･∀･`)ﾔﾚﾔﾚｰ
そんな感じですかね。
315:デフォルトの名無しさん
06/06/09 08:43:32
>>314
つまり、TemplateイラネをGenericsイラネにいまだに脳内変換してるバカってことか。
だれもGenerics神とか言ってねぇし。
スマソ、>>314自体が、そういうバカを装ったネタだったか。
316:デフォルトの名無しさん
06/06/09 10:13:17
>>313
いやどうみても>>311宛なんだが
317:デフォルトの名無しさん
06/06/09 10:14:20
>>315
まさにその通りだ。
たまにこのスレにでてくる馬鹿はC#厨とかＣ言語厨とかの
類だろう
318:デフォルトの名無しさん
06/06/09 13:15:36
Javaに要望されていたのはC++のtemplateじゃなくて、たんにparameterized typingじゃないの？
その意味でいえば、templateもgenericsも同じようなもんだけど。
あれか、templateイラネといっていた手前、genericsが導入されて引っ込みがつかないから
「genericsはtemplateとは違う、tempalteはいらないけどgenericsはマンセー」
といっしょうけんめい言ってるだけか。
大事なのは型引数がつかえることであって、コード生成なのかただのキャストなのかは
あんまり関係ないんだけど。
319:デフォルトの名無しさん
06/06/09 13:25:58
>>318
だから、導入したときにgenericsって名前にしたんだろ
320:デフォルトの名無しさん
06/06/09 23:16:20
俺の記憶じゃ、入れる前はどんなものか決まってなくて
C++のtemplate「みたいなの」が入るってことになってて勝手にﾜｲﾜｲやってたと思い
321:C++厨
06/06/09 23:32:26
C++風なのは入れないというのが暗黙の合意だったと思われ
あまり型システムは詳しくないけど、
Modula-3とかOberonの流れを汲むんじゃないの?
多重継承やオペレーターオーバーロードなし。特殊化なんてもちろんない。
322:デフォルトの名無しさん
06/06/09 23:54:27
タイプセーフenumパターンによるenumの実装は俺からしてみれば懸命だったと思うけど
ifよりswitchだみたいな風潮がまだあるのか、余り普及して内容に思える
323:デフォルトの名無しさん
06/06/10 00:05:13
タイプセーフenumの実現も可変長引数の実現も拡張forの実現も
みなGenericsのお陰で可能になったことなんだよ。
Genericsを導入するまでこれら三つを導入するわけにはいかなかった。
324:デフォルトの名無しさん
06/06/10 00:06:11
>>322
どういうこと？
enumはswitchでかけるし