次世代Javaの動向　２

次世代Javaの動向　２ ..

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でかけるし

325:デフォルトの名無しさん
06/06/10 03:17:28
次世代Javaスレなのに5.0で導入された機能の話ばっかりでつまらんので、
投下してみる。

JavaにContinuation（継続）機構は必要か？
URLﾘﾝｸ(blogs.sun.com)

俺はあんまり良く知らないんだけど、SchemeとかRubyにはContinuationという
機能がある。これは言うなれば、メソッドを呼び出す時に「おまえ、自分の処理
が終わったらこれを呼べよな」とクロージャを渡してしまう感じだろうか。

もちろんクロージャは（ちょっと前に話題に出てたけど）その時のスタック状態
さえも保持してるので（スコープから外れても、クロージャ内ではまだローカル
変数にアクセスできる、とか）、一種のlongjumpとして働くってことですな。
（というか、そこまでしか分からんかった....）

リターン値を見てから処理を決めて....という処理が不要になって、プログラムは
シーケンシャルにどんどん突き進めるという利点と、呼び出し元じゃなくても一気に
復帰できる上に、その時のスタック状態まで復元してしまうという、いわば「スタック
フレームごとあとで使うから保存しちゃえ」という強力な機能なんだってな。

なんだかContinuation-based Web Serverとかいうものもあるらしい。

で、この機能がJVM（JavaじゃなくてJVMだよ）に必要かどうかという議論。
リンク先ブログの人は、「ウェブアプリはAJAXとかで遷移の少ない方向へ移って
いってる過渡期で、移行が完了したらContinuation-based Web Serverの利点は
過渡期の遺物になっちゃう可能性があるし、JVMの大改造が必要だしセキュリティ
モデルに影響を与えるからイラネ」といってる模様。

いろんなサイト見て、Continuationは便利そうだが、正直分かりにくいし使いどころ
が難しい気がするので、俺もｲﾗﾈ、という感じだな。

326:デフォルトの名無しさん
06/06/10 03:43:38
JVMみたいなスタックマシンには継続は辛い。
欲しい新機能は、switchの代替になるようなパターンマッチング。
ラベルにGOTOするんじゃなく、値を返す奴がいい。
int result = match<Integer>(obj) {
　A : execute(); return 0;
　B : return -1;
　default : return 1;
}
って感じの。

327:デフォルトの名無しさん
06/06/10 06:24:44
>>325
細かいところだけど、ちょっとツッコミをば。

> これは言うなれば、メソッドを呼び出す時に「おまえ、自分の処理
> が終わったらこれを呼べよな」とクロージャを渡してしまう感じだろうか。

これは、継続渡しスタイル(Continuation Passing Style)と呼ばれるテクニックで、SchemeとかのContinuation
とは違う。SchemeとかRubyにある継続ってのは、call/ccと呼ばれるもので、1引数の関数を引数としてcall/cc
を呼び出してあげると、その関数を「call/ccの呼び出しが終わった地点に制御を移動するような関数」を
引数として呼び出してくれるという感じ。Javaっぽい文法で書くと、大体下のような感じになる。
このプログラムっぽいものを実行すると、ABCBCと表示される。

Continuation process() {
　Continuation result = null;
　System.out.print("A");
　call_cc(new Function(){
　　public void call(Continuation c){
　　　result = c;
　　}
　});
　System.out.print("B");
　System.out.print("C");
　return result;
}
...
first = true;
Continuation c = process();
if(first){
first = false;
c.jump();
}
System.out.println();

328:デフォルトの名無しさん
06/06/10 10:34:32
その前にproper tail call optimization可能なVMかな。

329:デフォルトの名無しさん
06/06/10 10:57:52
>>324
コンパイラがifに展開するんだとさ
int&switchによる高速さはenum&switchにはない

330:デフォルトの名無しさん
06/06/10 11:15:29
>>329
Enum.ordinal() 使ってint型にして switch するだけなんだけど。

この話も Mustang にも Dolphin にも関係ないね。

331:デフォルトの名無しさん
06/06/10 11:17:43
ん？実装が変わったのか？

332:デフォルトの名無しさん
06/06/10 11:29:36
>>329
>>330
俺もifに展開してると思ってた(というか、記憶が正しければ、
1.5のαかβではほんとにifに展開してたはず)のだが、今の実装は
確かにswitchを使うみたいだね。下のコードをコンパイルして、
逆アセンブルしてみたら、確かにEnum.ordinal()を使ってswitchする
コードに展開されてた。

public class TestEnum {
　enum AnEnum {A, B, C}
　public static void main(String[] args){
　　AnEnum a = AnEnum.A;
　　switch(a){
　　　case A: System.out.println("A"); break;
　　　case B: System.out.println("B"); break;
　　　case C: System.out.println("C"); break;
　　}
　}
}

333:デフォルトの名無しさん
06/06/10 18:15:07
>>332
実際にどう実行されるかは JVM 側のオプションでも変わって来るんじゃなかったっけ?

334:デフォルトの名無しさん
06/06/10 18:43:02
>>323
>タイプセーフenumの実現も可変長引数の実現も拡張forの実現も
>みなGenericsのお陰で可能になったことなんだよ。

なんで？
for (String str: list) {
　...
}
を
for (Iterator $it = list.iterator(); $it.hasNext(); ) {
　String str = (String)$it.next();
　...
}
に展開するだけだと思うんだけど、Generics関係なくね？

次ページ