- 1 名前：デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:03:42 ]
-
前スレ
【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/
関連スレ
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
pc8.2ch.net/test/read.cgi/tech/1094891986/
www.itmedia.co.jp/news/articles/0404/07/news018.html
マルチタスク実現へ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にも組み込まれる予定。
- 196 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:03:54 ]
- >>180
foreachはないけどfor(;;)やfor(;)はあるってことで
GenericsはあるけどC++Template相当のものはすべては無いってことで
「否定していた癖にJavaにforeachやGenericsが出た」と主張した奴は
馬鹿って事で
- 197 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:04:55 ]
- >>194
で、処理中にインデックスがいると分かり、for (int i = 0; i <
に書き直したり。これがアホくさい。言語レベルで今何番目か
分かるようにしてほしい。
- 198 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:05:48 ]
- >>184
それでも今Perl臭いヒアドキュメントの必要性は
感じないな。
JSFやStrutsがヒアドキュメント代わりになるというより、
>>170のようなHTMLコードをいちいちJavaコードの中に
埋め込むというくだらないことをしなくて済むという観点から
>>184の主張が現れている。
- 199 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:08:33 ]
- >>188
みんなって誰？
あれの需要はそんなにあるとは思えないな
- 201 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:09:54 ]
- >>192
ハードウェア方面にまでPureJavaをサポートするのは
まだまだ先だろ。
JiniやらJava Communication API をどうにかしないと
- 202 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:10:26 ]
- >>195
それはありうる。
>>193 >>195
というか偶然ともいえるだろう。
- 203 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:11:43 ]
- >>197
それはIteratorの意味が無いとちゃうか？
何番目を知りたいかだなんて使い方が間違ってると思うぞ。
アルゴリズムや作りたいものによるが、
コレクションの分割とか考えるといいかと
- 204 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:17:10 ]
- そもそもコレクションの機能にランダムアクセスなんてないだろ
interface RandomAccessとinterface Collectionは別の機能だ
- 205 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:18:04 ]
- >>203
間違ってるか？ というか、拡張 for 使いまくった？
えーと、そうだ、おまい今まで組んだものはループは全部 Iterator か？
例えば、画面に行No出力する場合はどうする？
JSTL とかテンプレート言語が無い場合ね。
- 206 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:20:21 ]
- >>197
俺もインデックスが必要になるのがあとで必要になって書き直したりするよ
でも、イテレータパターンであることを言語的に保証するものだからありでは？
インデックスだと中身まで見ないと流れが把握できない
>>201
キーボードやマウスと同じ一般的な入力インターフェースなんだが
ついでにMSXのようにキーボードもジョイスティック0番とかでつかえるようにしておけば
コードを分ける必要もなくていいのだが
同人ソフトとかでJava製の物がほとんどない原因のひとつでは？
フルスクリーン等は1.4でサポート、じゃヴぁSoundは1.3でサポートされやっと使い物になってきたが
インターフェースがないのではね
1.1時代＋JNIでなんでもできるということはなかったはずだし
JNIも万能ではない（スタックサイズ制限で引っかかる）からね
VM自体のリコンパイルが必要になるし、さすがにそれは現実的ではないだろう
- 207 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:25:27 ]
- > 同人ソフトとかで
を例に示されてもワカラネw
分かるのが普通か？
- 208 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:26:28 ]
- 「デスクトップ分野にも力を入れています」は口だけ
- 209 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:28:51 ]
- そんな大した手間じゃないと思うけどな＜パッド・スティック対応
PadListenerみたいな標準インタフェース用意して、メーカー側が対応するSPIをサイトに置いとけばいいじゃん
- 210 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:33:21 ]
- >>203
> 何番目を知りたいかだなんて使い方が間違ってると思うぞ。
それは言い過ぎだろw
けどループ構造は代えずにカウンタ一つ用意すればいいだけだよな。
- 211 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:34:44 ]
- >>209
sourceforge.net/projects/javajoystick/ にあるが、
標準でサポートしろって事でしょ。
けどジョイスティックはそもそもインターフェースが統一されているとは言いがたいし…
- 212 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:38:53 ]
- >>210
カウンタを用意するとループのスコープの外に変数を作ることになる。
なんかいや。
- 213 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:43:47 ]
- カウンタ用意したらイテレータパターンの意味ないだろ
何番目か意識することなく取り出すのが目的なんだから
カウンタ使いたければふつうにfor( ; ; )すればいいだけ
>>211
2軸32ボタンまではOSレベルで標準サポートされてるはずだ
- 214 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:46:49 ]
- だから、Iterator パターンでも、必要であれば、カウンタが
とれればいい。freemarker のように。
- 215 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:50:12 ]
- Iteratorのコード書くよりは拡張forの方がはるかに楽な件
Iteratorのコードの場合、カウンターが必要なら拡張for使わなくてもIteratorかカウンタ変数かどちらかがスコープの外に出る件
- 216 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:54:04 ]
- ジョイスティックが「デスクトップがんばる」の範囲に入ってなくてもほとんどの人が困らない件
- 217 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 13:01:36 ]
- >>215
ここで言ってるIteratorは拡張Forのことだという件
- 218 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 13:07:26 ]
- >>213
>>204の言っている意味も理解できないのかよ。
- 219 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 13:13:25 ]
- >>206
> >>201
> キーボードやマウスと同じ一般的な入力インターフェースなんだが
> ついでにMSXのようにキーボードもジョイスティック0番とかでつかえるようにしておけば
> コードを分ける必要もなくていいのだが
Adapterパターンでうまいことラッパークラス作れよw
- 220 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 14:12:33 ]
- >>216
ほとんど外の人がデスクトップ普及熱の根幹である件
- 221 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 14:22:25 ]
- >>219
みんなラッパつくってるだろ
それが面倒だということだろ
- 222 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 14:24:39 ]
- というかJ2SE5.0でデスクトップ改良部分ってなんかあったっけ？
1.4は明らかに今後がんばるんだなぁという光が見えたわけだが
- 223 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 14:39:46 ]
- ラッパならどこかでダウソできたような気がする
- 224 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 14:41:34 ]
- 5.0は思いつかない。
6はピュアGUIやスクリプトなど一応の発展はある。
- 225 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 16:28:04 ]
- Google Web Toolkitのような使われ方も次世代Javaか？
- 226 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 17:26:49 ]
- >>222
みんなOceanに腰を抜かしたはず
あのセンスに。
たぶん、アレで識者は「これは俺が何とかせねば」と奮起したと思われる。
インデックスが必要ということはカウンターが必要であるということで
コレクションを操作するという事とは別の要素が必要になったということ
繰り返し処理と、カウンタを使うという意味を切り分ける意味で
俺は別にカウンタを用意している。
カウンタも０からスタートさせたい場合や、1からスタートさせたい場合など色々。
もし、繰り返し処理で使うなら、拡張機能をさらに入れたい。それで
・カウンタの初期値
・カウンタのステップ
を決めたいのだが、そうなるとforeachタイプforにさらなる
文法拡張が必要になるなぁ。
for( Object i : list : 0 : 2 ){
}
あ、イテレーションのコンテキストにアクセスするのに文法も必要か・・・
コレは一筋縄じゃいかんねぇ
- 227 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 18:13:09 ]
- >>226
それだよ、それ。そういう拡張が欲しい。
スコープもループ内だしな。
- 228 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 18:29:05 ]
- >>226
もういっそのこと、Schemeのようなマクロを導入して、
そういう拡張は自分で定義してね、とするとか
まあ実際にはあり得ないだろうけど
- 229 名前：デフォルトの名無しさん [2006/06/04(日) 19:02:34 ]
- >>228
そういうのを要求する人はjavaの拡張を待つまでもなく、もうm4とかの
マクロプロセッサを使ってるんじゃないのかね。
- 230 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 19:07:58 ]
- Java のスレの中では初心者質問スレを除き、このスレが一番伸びている件について。
- 231 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 19:12:50 ]
- >>226
別に、普通に0ベースか1ベースのインデックスさえ手に入れば、
n + m * indexで、nまたはn+mからスタートしてステップmの
カウンタが手に入るじゃないの。
>>228
この程度ならマクロなんて必要なくて、レキシカルクロージャが
導入されていれば、簡単につくれるんだよねえ。
- 232 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 19:38:56 ]
- JavaSE6も近いからな
関係ないか
- 233 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 19:47:44 ]
- 中途半端な知識で参加できるからだと思われ
- 234 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 20:25:07 ]
- >>226
いらねー
くだらねー
- 235 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 20:39:03 ]
- Jakarta Velocityの変数$velocityCountみたいなのがあれば
いいんでね？
- 236 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 21:23:13 ]
- いらん
- 237 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 21:30:28 ]
- 普通はいらんね
- 238 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 21:53:15 ]
- >>231
レキシカルクロージャがあれば、その程度なら簡単にできる
というのはその通りだが、クロージャだけでは簡単にできない
拡張もある。で、諸々の拡張に対する提案全部を取り入れてたら
きりが無いので、マクロを定義する仕組みだけ用意して、あとは
ユーザが勝手にマクロを作ってねとしたらどうか？というのが228
で言いたかったこと。まあ、マクロは濫用される危険性が大きい
機能でもあるので、Javaのような言語に実際に入ることは無いだろうけど。
- 239 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 21:53:18 ]
- Freemarker の変数 $〜_index みたいなのがあれば
いいんでね？
- 240 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 21:56:02 ]
- イラネーよ、そんな糞機能
- 241 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 22:16:57 ]
- ロードまぷ
roumen.name/work/Poland06/Roman_Strobl_JavaSE_6_7_Roadmap.pdf
- 242 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 22:32:28 ]
- SPECJBB2000なんて字樹上にそぐわないベンチ使ってるのが怪しい
2005なんでつかわないのだ
1.2.2でノーマライズとかいてるのもあやしい
1.3.1とかなり違うはずなのだが
- 243 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 23:43:40 ]
- >>243
カウンタ用変数を外側に用意すれば?
もちろん｛ ｝で一段スタック入れてスコープ狭める
- 245 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 23:51:24 ]
- >>243
Iterator 大好きなんだな。
別にそこまで無理してデザパタ使わなくてもいいよw
- 246 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 00:10:39 ]
- ArrayListから配列取り出して
//こっちのほうがわかりやすいから
とコメントしてforで回してるソースを見たときは声出してﾜﾛﾀ
- 247 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 00:15:45 ]
- >>245は馬鹿だね
- 248 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 00:21:12 ]
- デザパタ厨的には、IndexableIteratorというデコレータを作るのかな。
- 249 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 00:35:13 ]
- Iterator パターンは内部を意識することなく順次取出しするのが目的であって
何番目とかの処理を意識させるのは必要ないからな
あなたは何番目ですか？がロジックで必要なら自前で用意するだけ
今までのfor構文でイテレータ使ってたのと同じでこれはかわってないだろ
- 250 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 00:38:23 ]
- >>245
必死だな
- 251 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 02:01:46 ]
- >245
ﾜﾛｼｭ
- 252 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 02:39:44 ]
- >>248
似たようなもんがJakarta Commons Collectionsになかったか？
- 253 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 02:52:50 ]
- Map用のfor文が欲しい
for(String key,String value : map) { 文 }
みたいな
- 254 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 03:02:43 ]
- Entryでいいじゃん
for(Map.Entry entry : map.entrySet() )
- 255 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 09:42:15 ]
- Iterator → デザインパターンってヤツは誤解しているぞ。
IteratorはCLUで70年代からある。
- 256 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 11:46:58 ]
- >>253
MapをIteratorに変換するか
MapとListが一緒になった、Jakarta Commons Collectionsにある
あのクラスを使えば医院ジャマイカ？
- 257 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 11:47:34 ]
- >>255
GoFの一つにIteratorパターンがあるからね。
デザインパターンとしてのIteratorは後から出たモノだとおもう
- 258 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 11:51:11 ]
- >>254
それだと、Entryからkeyとvalueを取り出さなきゃいけないじゃん。
253だとその手間が省ける。それが大事。
- 259 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 12:04:53 ]
- そこまで大事か？
- 260 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 12:40:00 ]
- >>259
まあ、あれば便利かもしれんが、そこまで重要な機能ではないわな。
foreachに比べると、使う機会も少ないだろうし。
- 261 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 19:25:26 ]
- つうか、>>253くらいのことは簡単に実装できるんだから、拡張for文を導入するときに
いっしょに導入してくれればよかったんだよ。
そのくらい、ふつうに気がつくだろ。なんで直接Mapが使えないように限定するのかさっぱりわからん。
- 262 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 19:40:33 ]
- >>261
そんなこと言ってると
あれも入れろこれも入れろで収拾付かなくなるから。
- 263 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 19:49:14 ]
- Entry回せばいいじゃん、極一部のクラスのためだけにそんな馬鹿な仕様取り入れるかよ
Collectionはデータ構造に関するJavaの主要フレームワークの根元だから特別視されるだけだ
- 264 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 20:08:49 ]
- try-open-finally-closeも特別扱いしてほしい。
- 265 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 20:13:57 ]
- try-finallyデストラクタを強制するためにも
openとcloseは例外を投げる設計にしたほうがいいんだよな
>>264
どんな感じの？
- 266 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 20:40:25 ]
- >>262
そのくせプロパティやらXML直書きやらは導入されるんだ。
そっちのほうが収拾つかんわ。
- 267 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 20:44:59 ]
- >>266
Map の foreach なんて generics+プロパティ導入で e.key と e.value で済むんだから
わざわざ入れなくてもいいだろ。
- 268 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 22:08:03 ]
- クロージャが出来るそうだから、
foreach(aMap, クロージャ);
でいいよ。
- 269 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 01:47:50 ]
- クロージャは導入必至。
オヤジJavaプログラマの「クロージャは苦労じゃ」のネタは既に
あるものとして色々なバリエーションが考えられてるからです。
どんなものでもイイが、上のネタを生かすために簡単なものであっては困る事だけは確かだ。
- 270 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 02:25:33 ]
- クロージャの正しい概念ってどんなの？
ECMAScriptだとthis参照を遅延生成メソッド内に埋め込むやり方で使ってるよね
でもJavaのthisってコンテキスト参照じゃなくてインスタンス参照でしょ？
- 271 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 02:44:45 ]
- XMLリテラルがどういう利点があるかわからないんだけど。
- 272 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 03:11:42 ]
- >>271
構造を持ったデータを簡単に作れることじゃないの？
今までせこせこ、ＬｉｓｔとかＭａｐとか組み合わせてたような奴
- 273 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 03:28:52 ]
- アノテーションにxmlリテラルが使えると、外部xmlファイルが必要なくなるのは嬉しいか嬉しくないか微妙。
- 274 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 08:35:14 ]
- >>270
foldoc.org/foldoc.cgi?query=closure&action=Search
の1かな。
Javaに実装するなら、new Callable() { ... } あたりを楽に書ける
シンタックスシュガーとして実装がいいんじゃない。
つまり、ローカル変数はfinalなもののみアクセスできる。
>>36 のようなことがやりたければ、
final int[] sum = { 0 }
で切り抜ける。
- 275 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 20:11:40 ]
- 使い勝手が悪そう
- 276 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 04:21:46 ]
- ヒアドキュメントすら否定するのにXMLリテラルは受け入れるJava厨乙
- 277 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 05:45:45 ]
- >>276
受け入れてないよ。だからヒアドキュメント否定するんだろ。
- 278 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 05:49:46 ]
- とか言いながら、いざ実装されるとマンセーするのがいつものパターン。
- 279 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 07:45:12 ]
- ヒアドキュメントはイラン。
ところで、クロージャーって、単なるシンタックスシュガーじゃなくて、スクリプト言語用のバイトコード拡張を利用する構文じゃないのかな。
- 280 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 11:05:11 ]
- >>279
それは激しい・・・
ヒアドキュメントと変わらんじゃないですか
スクリプト言語のシンタックスがわからない以上・・・・
- 281 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 11:13:26 ]
- >>279
それはまず無い。スクリプト言語用のバイトコード拡張(invokedynamicだったか)は、
クロージャの実装に使えるようなものじゃない。クロージャが単なる匿名クラスの
シンタックスシュガーになるんじゃないだろうというのは同意だが、クロージャは、
別にバイトコードを拡張しなくても、既存のコードの互換性を保った形で追加できるはず。
- 282 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん [2006/06/07(水) 11:45:10 ]
- >>280
三行とも意味がわからん…w
Groovyの文法は既に定義されているし
- 284 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:35:22 ]
- >>261
なにも考えずに下手に導入するとC#やC++の二の舞となるぞ。
どうしてもそういう機能が欲しければ
C++やC#で実装して貰うように頼むか自分で実装するという手もありだな
- 286 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:41:34 ]
- ああ、実引数の間違いね。
Closureを実装するにあたって、
JVMの仕様を変えるという話は出てきてないから、
ほとんどsyntax sugarみたいなもんなはずだけどね。
というかinner anonymous classがほとんどclosureみたいなもんだし。
finalが外れるとしても、primitive typeの扱いはどうするのか…
- 287 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:43:31 ]
- >>285
つーかクロージャができる今となっては>>268でいいでしょ。
拡張forは黒歴史だ。
- 288 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:51:02 ]
- >>286
JVMの仕様を変えないでも、「本物の」クロージャは実装できるよ。
あと、キャプチャされる変数がprimitive typeかどうかは、クロージャ
実装するにあたっては、特に関係無いはずだけど、何か問題ある？
- 289 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 13:38:10 ]
- ローカル変数も基本型だとスタックフレームにあるから、
オブジェクトでラップしとかないといけないよね。
外に持ち出して複数のクロージャから参照されるかもしれないから。
- 291 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:17:14 ]
- >>289
それは、クロージャからouter classのフィールドを参照しているか
outer scopeのローカル変数を参照するかによる違いであって、
primitive typeかどうかは関係無いのでは？クロージャから
outer scopeのローカル変数を参照可能で、かつ、クロージャから
その変数が変更可能なようにする場合、基本型かどうかに関わらず、
オブジェクトでラップする必要が生じると思うんだが。
- 292 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:54:33 ]
- >>283
あのースクリプト言語ってGroovyだけじゃないんですが・・・
スクリプト言語への対応って言語の定義はされてなくて、APIの定義なんですよ。
おそらくそこを勘違いされていますよね？
今あるスクリプト言語だけじゃなくて将来出てくる言語もこのAPIに沿ってライブラリを
用意すれば使えるっていうフレームワークです。
- 293 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:57:25 ]
- 今までずっとコンパイル言語はデリゲート、スクリプトはクロージャって漠然と思ってたけど
もしかしてもっと高尚な概念だったのか？ｗ
- 294 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:04:53 ]
- スコープがどこにあるかで変わるような気もするが
デリゲートっていうのはクロージャーよりもっと大きな範囲を表すことばじゃないか？
- 295 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:05:00 ]
- >>293
別に高尚というほどのものではないが、ある言語がコンパイル言語かスクリプト言語
かどうかと(この区別の仕方も問題大有りだがそれは置いとく)、その言語がクロージャ
を持っているかどうかは全く関係が無いことは確か。あと、デリゲートってたぶんC#の
デリゲートのことを言ってると思うんだが、あれはMS用語であって、C#のあの機能に
対する用語としては全く一般的じゃない。
- 296 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:09:16 ]
- D言語もdelegateだろ？そのうち次世代標準になると思うが
|
 |
