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でかけるし
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関係なくね？
335:デフォルトの名無しさん
06/06/10 18:59:16
>>324
おまえはtype safeという意味がわからんのか？
336:デフォルトの名無しさん
06/06/10 18:59:49
>>320
おれの記憶だとparameterised typingが希望されてて、その例としてC++のテンプレートが挙げられていた。
C++のテンプレートそのままが欲しいやつっていたのかな。欲しかったのはあくまで型引数がつかえることじゃない？
でも昔はGenericsとかGeneric Programmingという言葉はあまり浸透してなかったから、
話としては「テンプレートみたいなのが欲しい」という表現がよく使われていた。
つまりC++のテンプレートが欲しいんじゃなくて、型引数が欲しかったということ。
だから
>>172
>いっておくがC++のtemplateとJavaのgenericsとはまったく別もんだよ。
のようなのには、なんというか話がずれてるように思える。
どっちもparameterized typingなんだからおんなじじゃん？実現方法を問題にしてるんじゃないんだよ。
C++のtemplateは否定してJavaのgenericsは肯定してるやつらって。
まあいつものことか。
337:デフォルトの名無しさん
06/06/10 19:12:04
>>336
templateを否定してgenericsを肯定してるやつらは
template固有の話を問題にしているんだから、
>>336と話が合うはずがないよ。
とｵﾓﾀ。
338:デフォルトの名無しさん
06/06/10 19:15:50
>>336
実現方法を問題にしてたんだよ。
339:デフォルトの名無しさん
06/06/10 19:18:29
6.0って構文に関するなんかって変わるっけ？
5.0と7の間にあるバージョンだから、印象が薄すぎて・・・
340:デフォルトの名無しさん
06/06/10 19:23:50
5と7の間だとなぜ薄いのかよく分からない
341:デフォルトの名無しさん
06/06/10 19:33:15
そらおまえ、GenericsだのXMLリテラルだのキモイ仕様てんこもりじゃないか
342:デフォルトの名無しさん
06/06/10 19:37:36
>>335
流れおかしくないか？
343:デフォルトの名無しさん
06/06/10 19:44:29
>>340
5と7は変更が大きいからね。
6はもともと5.1になる予定だったわけだし。
344:デフォルトの名無しさん
06/06/10 19:55:18
5.0は言語仕様の変更は大きいけどAPI的に1.4とくらべてたいした進化はない
せいぜいコンカレントまわりくらい
６は結構大きい変更が多いので楽しみ
中でもSwingの大規模修正はびっくりなくらいでは？
345:デフォルトの名無しさん
06/06/10 19:57:32
あのバタ臭い見た目は何とかして欲しいけどな。
346:デフォルトの名無しさん
06/06/10 20:22:20
デフォルトのLAFはSystemLAFでいいようなきがするな
347:デフォルトの名無しさん
06/06/10 20:22:49
お前はバタ子さんに恨みでもあるのか
348:デフォルトの名無しさん
06/06/10 23:06:59
>>344
Swingの大規模修正ってどんなの？
あんまり詳しくないので純粋に聞いてみる。
最近Swingに興味を持ったもので....
349:デフォルトの名無しさん
06/06/10 23:50:35
>>334,335
foreachに関してはともかくtype safe enumは
Genericsのおかげで「簡単になった」。
タイプセーフの実装は、自分で色々書けば出来たよ。
Effective Javaとか読んでみないか？
350:デフォルトの名無しさん
06/06/10 23:53:57
>>348
えーっと、漏れは>>344じゃなくて何が大きいか何とも言えないが、
個人的に助かってるのは
・GroupLayoutの搭載
・WindowsLAFの改善
・サブピクセルAAレンダリング
あたりかな？中では最適化がかなりゴロゴリありそうだけどよくしらない。
351:デフォルトの名無しさん
06/06/11 00:05:12
>>349
type safe enumを定義するのに、Genericsはほとんど使わないわけだが・・・。
352:デフォルトの名無しさん
06/06/11 00:06:10
enum A{ ONE, TWO, THREE}
のどこでGenericsがいるのだろうか。
353:デフォルトの名無しさん
06/06/11 00:19:01
>>351
>>352
Java 5.0のAPIドキュメント見ればわかるけど、列挙型の基底クラスである
java.lang.Enumの定義自体にGenericsが使われているよ。
354:デフォルトの名無しさん
06/06/11 00:23:07
>>353
Effective Javaのtypesafe enumの実装みたことあるのか?
355:デフォルトの名無しさん
06/06/11 00:37:25
>>350
一番大きいのはAWTスレッドがとまっていてもウインドウが描画されることかと
あとはJava2DでOpenGLパイプラインがLinux系でデフォになるようでクライアント分野も
DirectX使ってるWindowsに速度的に追いつくかなと
ただ、5.0のOpenGLサポート見てると非常に期待が出来ないのだけれども
JOGL使ってるなら大丈夫かな
つーかJOGL標準APIにしてください
>>354
そういうこといってるわけじゃないだろ？たぶん
356:デフォルトの名無しさん
06/06/11 00:49:22
>>354
そりゃもちろん見たことある。というか、何故Effective Javaのtypesafe enumの
話になる？Java 5.0のtypesafe enumがEffective Javaのそれが元になっている
のは知ってるが、全く同じというわけじゃない。
357:デフォルトの名無しさん
06/06/11 01:00:42
>>356
そりゃGenericsがなくてもtypesafe enumが作れるからだろ
GenericsがないとJava 5.0と全く同じものはつくれないけど
typesafe enum自体はつくれる
Genericsのおかげで作れたなんて変だって話でしょ
358:デフォルトの名無しさん
06/06/11 01:18:45
>>357
いや、そりゃtypesafe enum自体はGenericsが無くても作れるけど、
Enum同士のcompareToによる比較などが型安全にできないでしょ？で、>>349は
そういうのを指して
> foreachに関してはともかくtype safe enumは
> Genericsのおかげで「簡単になった」。
と言っていると思ったんだが。あ、もちろん>>323の言っている
ことは変だと思ってるけど、>>351や>>352は>>349に対する言及
だと思ったので。
359:デフォルトの名無しさん
06/06/11 02:07:13
Generics とか enum とか、Tigerで追加された機能の話題はこっちでやったら？
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
ｽﾚﾘﾝｸ(tech板)
360:デフォルトの名無しさん
06/06/11 02:50:30
いいんじゃないの？ここで。
361:デフォルトの名無しさん
06/06/11 03:31:27
Generics とかは現行世代の機能だから次世代スレでやるのは筋違いでしょ。
362:デフォルトの名無しさん
06/06/11 04:28:00
流れってもんも大切だし、極端に筋違いなわけではないし、そもそもこのスレの「次世代」というのは、Mustangスレの次スレをTigerスレでやろうかという意見があったときに、じゃあ次世代Javaというスレをたててまとめてというのがあったわけだし。
363:デフォルトの名無しさん
06/06/11 04:29:13
それに、enumとかGenericsとかについて意見が食い違うという時点で、次世代ということにしてもいいと思うわけで。
364:デフォルトの名無しさん
06/06/11 08:59:34
>>358
compareTo以外に何かある？
365:デフォルトの名無しさん
06/06/11 13:03:25
なんか一人genericsが嫌いなやつがいるようだな
366:デフォルトの名無しさん
06/06/11 15:11:08
>>325
それはWeakest Post Conditionという奴か？
ならば、Template Method パターンまたはアスペクト指向で
実現できまいか？
367:デフォルトの名無しさん
06/06/11 15:15:06
>>334
展開する前の前処理にGenericsが関与してるに1バイト
368:デフォルトの名無しさん
06/06/11 15:23:10
>>351-352
EnumクラスのJavadocを見ると
Enum<E extends Enum<E>>
使われて無くはない。
Genericsが使われているかいないかで
Javaのenumの仕様がかなり異なってくる。
C/C++のようなtype unsafeなenumにするわけにはいかないから
Genericsを導入するまでenumを導入するわけには
いかなかった理由がよくわかる。
369:デフォルトの名無しさん
06/06/11 15:24:19
>>357
Genericsのお陰で作りやすくなった
以前より比較的正しいenum実装ができるように
なった、とでも言うべきだろう。
370:デフォルトの名無しさん
06/06/11 15:29:58
>>364
equals(), clone(), hashCode(), toString(), valueOf()
371:デフォルトの名無しさん
06/06/11 15:47:30
>>362
そのMustangの話題ですらないわけだが。
372:デフォルトの名無しさん
06/06/11 15:55:01
今後はもうベンチマークに期待できなくなってくるのかな
Swing周りの改良は今後も進むかもしれないけど、業務では変わらない？
JVM統合の流れになっていくのかな
373:デフォルトの名無しさん
06/06/11 16:14:19
>>367
くわしく
374:デフォルトの名無しさん
06/06/11 17:15:01
>>372
業務でSwing使えばいいじゃない
すでに社内システムはWEBアプリは衰退していてリッチクライアントが普及してきているよ
不特定多数ならWEBアプリだけど、開発効率が段違いにわるいので
コスト増が問題になってるという感じ
375:デフォルトの名無しさん
06/06/11 20:23:42
今更であれだけど、Genericsっていいの？
コンテナに間違ったモノ突っ込むなんてバグはもとから経験無いけどなぁ。
376:デフォルトの名無しさん
06/06/11 20:50:16
キャストが要らないからそのままメソッド呼べたり、すっきりするってのが一番の恩恵でしょ。
377:デフォルトの名無しさん
06/06/11 20:58:09
自分だけで作ってるとあまり恩恵はないね
他人の作ったコード呼ぶ部分でListとだけ書かれてると困るので助かる
JavaDocとか整備されてないライブラリとかで泣きながらソースよんで苦労することが減った・・・
List<Map<Key,Value>>とか業務系だと頻繁に使うしね
大規模開発こそ結合部のドキュメント系が必要なのに整備されている率が低い傾向にあるのはどういうことだろう
ウォーターフォールの出来上がってくる設計書類にそんなものがまったくないという
少人数でライトウェイトな開発していればまずインターフェース作りましょうとかドキュメントは
大事なところだけ書いてあとはJavaDocにガンガン記述していきましょうとかそういうのが多いな
とりあえず何も考えなくてもよくなるEnumはかなり恩恵があるのは確かだが
378:デフォルトの名無しさん
06/06/11 21:09:27
>>370
valueOf はそうだけど、他は関係ないような気がするよ。
379:デフォルトの名無しさん
06/06/11 21:13:13
>>377
そのList<Map>構造の部分、今度はXMLになるかもね
また構造わかんねｗｗｗｗ
380:デフォルトの名無しさん
06/06/11 21:16:08
>>375
例えばMapでキーや値の型を仕様変更した場合に、
根っこの一箇所変えれば
コンパイルエラーがどこを直せばいいか教えてくれるのが楽。
ってのもある。
381:デフォルトの名無しさん
06/06/11 21:18:59
>>372
JVM統合って何？
382:デフォルトの名無しさん
06/06/11 21:23:26
-serverオプションが消えるとか
383:デフォルトの名無しさん
06/06/11 21:36:46
>>375
間違ってダウンキャストしなくて済むし
いちいちドキュメントにこの型にはこれ以外入れるなとか
書かなくて済む。
384:デフォルトの名無しさん
06/06/11 21:38:12
>>378
Enumの中に入れ子になっているオブジェクトの型が一致しなかったら
あれなのでequals()とか、hashCode()も重要
385:デフォルトの名無しさん
06/06/11 23:04:03
業務系のソフトウェアでは、Mapの中にMapが入っていて、しかもそのMapの要素は
Listが３つ、なんてざらにある。
で、そのListに何が入っているのかはドキュメント化されてないし、うっかりしてると
Mapを入れるべきところにListを入れてしまったり....と、orzになる機会は山ほどある。
genericsについていろいろ言われているようだけど、Collectionフレームワークの型
安全性を高めるという点について「ｲﾗﾈ」と言ってたﾔﾂを俺はしらないな。
Goslingﾀﾝもそこをとても重視していたみたいだよ。ソースが見つからないがそんな
こと言ってた。
386:デフォルトの名無しさん
06/06/11 23:19:53
genericsいらないって言っていた馬鹿は探せばいるだろ。
どんな馬鹿でもいるもんだから。
そんな馬鹿が手のひらを返してgenerics便利だと言ったところで一体なんだというのだ?
387:デフォルトの名無しさん
06/06/11 23:21:55
しかし今頃この話題が出てきたということは6が出そうなこの時期に
やっと5.0つかった開発がスタートしはじめているということだろうか
388:デフォルトの名無しさん
06/06/11 23:24:02
>>386
何でもない
いや、それがこの話の結論のはずなんだが
それで納得できない暴れたい盛りのやんちゃ坊主がたくさんいてな・・・
前向きでない議論は無駄。
現行Genericsの不備点を挙げて、こうなればいいのに・・・とかいう話ならまだ広がるんだが・・・
389:デフォルトの名無しさん
06/06/11 23:31:53
>>387
そろそろドカティもJava5に入り始めるんじゃない？
390:デフォルトの名無しさん
06/06/12 00:03:01
>>389
・)ﾉｼ
1.3で開発してるドカティが来ましたよ
こんな太古のアプリ改造するくらいなら新規で作れよそもそも設計からして腐ってんだからさぁとか言いながらコード書いてますよ
5で書きたいよぅ>>377が言ってる問題にぶちあたりまくりで元からバグバグなコードいじる度にビクビクしなきゃならんのは嫌だ
391:デフォルトの名無しさん
06/06/12 00:18:57
>>390
そういうなおいらは去年ようやく1.1から1.4へのUpgradeに成功した
2年ほど前に出した見積がようやく日の目を見たって所だ
392:デフォルトの名無しさん
06/06/12 00:26:07
保守的な奴らが居るとうんざりするときあるな
1.4.2で作ってるんだが、_??の部分までぴったり合わせるよう指定が来る
いやいや、それってバグフィクスのバージョンだろと突っ込みたくでも突っこめない
仮にバグっててもそれのお陰でうまく動いてるのを当てにするんだろうな
393:デフォルトの名無しさん
06/06/12 00:27:19
>>391
なんか生き残れるのか心配になるようなローペースさだな。
394:デフォルトの名無しさん
06/06/12 00:50:10
>>389
J2SE5.0使ったシステム2つうけてるけど、ついていける人とついていけない人がやはり現れますな
勉強し理解する人は5.0すごくよくなってるといい、勉強しないで分からないというだけの人は
なんでこんなバージョンにしたの?といってくる
知的労働者なんだからまったくついていけないようだったら首を切るのを勧めたほうがいいだろうね
そういうのはだいたいCOBOLメンテしてきてVBやってる人に多いかと思えばそんなことはなく
COBOLもしってCもやれてJavaもきっちりしってる人も割と多い
言語の得て不得手をしっかりと理解できているかどうかはが大事
逆にJavaやCでずっとWEBアプリ業務でやってきましたという人種でもかなり危険なやつらが多い
1メソッド数百行をスコープ範囲狭めることなく平気で書くのが特徴だから分かりやすいといえばそうなのだが
395:デフォルトの名無しさん
06/06/12 01:34:52
>>392
涙が出るほど共感を覚えるが、スレ違いではあるまいか
396:デフォルトの名無しさん
06/06/12 01:46:24
雑談スレだし、いいんでないの？
397:デフォルトの名無しさん
06/06/12 02:19:45
いったいいつから雑談スレに.....orz
398:デフォルトの名無しさん
06/06/12 03:55:55
_XXを気にするなんて、まともな所なら常識だろ。
_XX変えたらテストやり直し。保守的とかじゃなくてブロの常識。
399:デフォルトの名無しさん
06/06/12 04:23:10
まともなところとかまともじゃないところとかは関係ないと思うな。
常識かどうかも。
そこまでの信頼性が求められるかどうかだと思われ。
信頼性もとめるなら、まだJava2SE5.0は使えないんじゃないかな。
400:デフォルトの名無しさん
06/06/12 04:32:56
ただ、障害が出たときのサポートと、サポート期間考えると最新使わないわけにもいかない
5年単位の利用期間に対して、それ以前にSUNのサポートが切れるJVM使うのもできないし・・・
1.4.1のGCのバグで散々な目にあったよ・・・orz
しかし、Tigerはそろそろ使えるようになってると思うんだが・・・
Mustangが出るってのに2世代前しか信頼できないって状況はないんじゃない？
というか、信頼性なんて自分たちで確かめるもんだし。
401:デフォルトの名無しさん
06/06/12 05:56:32
ハイエンドのサポートはSunだけじゃないからな。
自分達で確かめれる程度の信頼性なら、自分達で確かめればいいと思う。
402:デフォルトの名無しさん
06/06/12 06:13:52
使う範囲で信頼できれば十分だからね。
403:デフォルトの名無しさん
06/06/12 10:58:35
>>398
それにかかるコストを誰が払っていると思っているんだ。
誰も払わなければやるだけ無駄でSunに踊らされているだけだろ。
ちょっとバージョンアップしたくらいでまたそのバージョンに
遭わせて無駄に過剰テストして無駄に管理を厳しくするのは
コストの無駄。テストの自動化もできない奴がそういうことをしたがる。
404:デフォルトの名無しさん
06/06/12 11:09:35
自分の常識が世の中全体の常識と思ってるヤツがいるな。
405:デフォルトの名無しさん
06/06/12 11:24:21
>>403
問題が出てからの対処で良いならその考え方もあるが
何でか知らないが開発会社に全てのコストを押し付ける顧客が多すぎるよな
やって欲しいならそれに見合う金を払えってんだ
406:デフォルトの名無しさん
06/06/12 12:30:30
>>403
おまいは、安かろう(品質)悪かろうのシステムしか経験がないのかも知らんが、
それを一般化するなよ。>>399の言う通り、どこまで品質が求められるかどうかがポイント。
自分の基準で過剰テストだの無駄だの、安物PGにしか見えないからあまり言わない方がいいよ。
だいたい、テスト自動化となんの関係があるんだか…。
407:デフォルトの名無しさん
06/06/12 13:19:56
>>406
ひとこと言わせて貰うと、お前は考え方が古い。
20年くらい前のCOBOLerが大好きながむしゃら管理手法で
やっている。
Java5でないとうごかない製品ももうすでにかなり出ている。
すでにJava5は実績としてはかなりのものだ。
408:デフォルトの名無しさん
06/06/12 13:39:06
もはや Generics の話題ですらないな。
説教したい/されたいならマ板でどーぞ。
409:デフォルトの名無しさん
06/06/12 13:45:06
おれはJavaSE5が使えんとは書いてないが…。
運用トラブルリスクはそっちのけで安価・短期が最優先という考え方もアリだろう。
だが、システムの必要品質を確保するのに、古いも新しいもない。全然理屈になってないよ。
そんな事言ってると、底辺PGとバレるから気を付けた方がいいぞ。
というか、テスト自動化されてんなら、テストやり直しに何でファビョってんの？
410:デフォルトの名無しさん
06/06/12 15:26:14
商用アプリサーバのＳＥ５のサポートって
最近じゃない？
やっとベンダにとって、サポートコストがぺイするレベルに枯れてきたって事か。
411:デフォルトの名無しさん
06/06/12 15:34:32
どっちがファビョってるんだか。
たまにJavaすれにVBあがりのドトネト厨が
割り込んで来ることがあるけどそれ系の厨かなw
412:デフォルトの名無しさん
06/06/12 15:36:07
>>410
商用じゃなきゃ信用できない
なんていったらLinuxがアップデートされるたびに
過剰テストにものすごく無駄に時間をかける羽目になるんだが。
Java5の枝番号が変わっただけでその都度細かいテストするのも
まさに効率悪い。
413:デフォルトの名無しさん
06/06/12 16:19:10
全員スレタイ見直してくれ・・・頼む・・・orz
414:デフォルトの名無しさん
06/06/12 17:28:41
まあ、この手の素人PGが次世代Javaのバグ出しをしてくれて、
堅いシステムにも使える様にしてくれる、と言うことで。
415:デフォルトの名無しさん
06/06/12 18:04:05
素人PGがまともにBugParade登録出来るとも思えないけど。
Genericsの現実的な使いどころって、
コンテナ（ぽい）オブジェクトの中身の明示以外どんなのがある？
416:デフォルトの名無しさん
06/06/12 20:10:02
>>412
おまえ、ハイエンドの品質の厳しさわかってる？
417:デフォルトの名無しさん
06/06/12 20:10:44
>>413
次世代Java厨の動向
418:デフォルトの名無しさん
06/06/12 20:15:15
>>415
type safe enumだろ (以下ループ
419:デフォルトの名無しさん
06/06/12 20:38:31
>>415
Observer/Observableを型安全に使えるようにするとか。
残念ながらJava5のそれは、Generics対応になってないが。
あとは、コンテナと無関係ではないが、型に依存しないアルゴリズム
のライブラリ化とか。C++のtemplateみたいに、今までできなかったことが
できるわけじゃないので、今まで型安全にできなかったこと(Object型で代用して
いたこと)を型安全に行えるようにする、というのが主な使い道じゃないかなあ。
420:デフォルトの名無しさん
06/06/12 21:30:17
仮定のない品質など議論する意味はない。
>>419
俺もそう思う。
Objectを突っ込みまくっていた部分を見直して
綺麗なロジックが書きやすくなるという部分かな、と。
アスペクトとまでは行かないけれど、ロジックだけを切り出して
実装できるのも、何という機能というわけじゃないけど面白い。
言ってみれば、Map,ListなどGenericsの恩恵を直に受けたライブラリは
そのMap,Listという振る舞いを型に依存しないで実装できたいい例だったということだから。
421:デフォルトの名無しさん
06/06/12 23:09:20
で、ながれを戻そうとしてもなぜ現世代Javaの動向に戻るんだ？
次世代はどうした。
422:デフォルトの名無しさん
06/06/12 23:39:48
んじゃ次世代らいく・・・
お馬さんのJava2Dレンダリングどーなってるの？
Windows版はデフォはDirectXのまま？
あいかわらずほとんどの描画がアクセラレーションきかないの？
423:デフォルトの名無しさん
06/06/13 02:31:28
>>421
次世代Javaプログラマの動向
424:デフォルトの名無しさん
06/06/13 10:33:25
そもそもJavaプログラマの定義なんて曖昧。
煽ってる奴やJavaが嫌いな奴はJavaプログラマ＝Javaしかできないプログラマと
脳内変換して話を進めたがるから話が当然噛み合わないわけだし。
実際に、Javaの仕事をするときにJavaしか知らないでは、まったく
仕事ができないものだが。
425:デフォルトの名無しさん
06/06/13 10:35:03
>>424
実際にJavaしか知らないって奴がいっぱい居るじゃん
まあそういう奴はJavaすら知らないって事が多いけど
426:デフォルトの名無しさん
06/06/13 11:04:30
だから
Javaしか知らない奴
という表現は論理的に矛盾していると
427:デフォルトの名無しさん
06/06/13 12:17:24
続きはマ板で。
本当に底辺野郎じゃなければ
もっと融通が利いているはず。
428:デフォルトの名無しさん
06/06/14 00:10:18
なんだが、Genericsを否定したい奴がいちゃもんつけてるようにしか見えないな。
彼の主張は「C++Templateはいらないと言ってい他奴がGenericsは欲しいと言いだした」
ということらしいがな。
彼の脳内ではC++Template == Generics
でないと気が済まないようだ。
429:デフォルトの名無しさん
06/06/14 00:34:43
もうGenericsは入ったんだから便利に使おうぜ。
それよか、久々にMustang案内入れるか・・・
Mustang b87
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(www.java.net)
changeを見ると壊れてんのかな？と思うが新しいフィーチャーはない。
Java SE 6.0 Release 1 Developer Preview 3
URLﾘﾝｸ(connect.apple.com)
Appleも追従してDeveloperPreviewを出してきている
こちらはb82ベース
NewFeatureは
* Applet support (plug-in)
* Java Web Start
* Java SE 6 Java Preferences utility
PowerPCのJITはまだらしい。
430:デフォルトの名無しさん
06/06/14 01:12:23
>>429
> PowerPCのJITはまだらしい。
というかMacはもう…
431:デフォルトの名無しさん
06/06/14 10:30:43
えーと、CocoaにはJavaAPIの新規追加はもうない、って話かしら?
432:デフォルトの名無しさん
06/06/14 11:04:34
PowerPC終了でしょう？
433:デフォルトの名無しさん
06/06/14 12:31:07
>>428
どうしてもtemplate!=genericsにしたいようだが
parameterized typeという点ではどっちも同じ
仕組みが違うのはあたりまえ
434:デフォルトの名無しさん
06/06/14 12:37:43
Javaから見たらgenerics≒templateで良いじゃないか
435:デフォルトの名無しさん
06/06/14 13:04:04
>>433
いや、違いすぎるだろ。
C++ templateはかなり独特だから。
436:デフォルトの名無しさん
06/06/14 13:32:58
>>428 >>433 >>435
3人ともtemplate!=genericsと言ってるのに論争になるのﾜﾛｽ
437:デフォルトの名無しさん
06/06/14 13:49:42
ところで、>>1のマルチタスクの実現ってのはどうなったんだ？
既に実装済み？
438:デフォルトの名無しさん
06/06/14 14:26:33
>>436
template<genericsとtemplate>genericsとtemplate>>>genericsじゃ論争になるだろ
439:デフォルトの名無しさん
06/06/14 14:38:50
template<genericとtemplate> generics
と区切ってしまい、何のことかわからんくなってた。
440:デフォルトの名無しさん
06/06/14 15:55:59
それぞれどういう意図で発言しているかがつかみずらいが、
もし、templateとgenericsが実現の仕組みが**多少**違うくらい
で、同じようなものだと思っている人がいるとしたら、もうちょっと
(C++の)templateのことを勉強した方がいいと思った。実際、
templateとgenericsはある程度までは同じ目的で使えるが、
かなり違うセマンティクスを持っている。優劣をここで述べる
つもりは無いが、それだけは確かだ。
441:デフォルトの名無しさん
06/06/14 16:19:17
>>439
おまえまだgenericsに慣れてないな。
「genericsとtemplate」を扱えるtemplate<?>型のgenericsという変数を宣言しているのだよ。
442:デフォルトの名無しさん
06/06/14 17:00:18
お前ら、頼みがある。Genericsに関しては既に実装された機能だから、他のところでやってくれないか。
せっかく新ネタ持ってきてくれてる人がいるのに、いつまでも粘着しないでおくれ。
443:デフォルトの名無しさん
06/06/14 17:06:45
>>442
劣勢だな。
流れだし、いいんでねぇの？
444:デフォルトの名無しさん
06/06/14 17:22:21
>>443
マ板的なネタで盛り上がるぐらいなら閑散としてたほうがマシ。
445:デフォルトの名無しさん
06/06/14 17:39:26
そうかなぁ
446:デフォルトの名無しさん
06/06/14 18:25:45
>>438
templateクラスがgenericsとtemplate型をパラメータに持って
と思ったらなんだその文法わ
447:デフォルトの名無しさん
06/06/14 18:48:06
6のSwingはWindowsOSにも恩恵はありますか？
448:デフォルトの名無しさん
06/06/14 19:31:09
恩恵ってなんですか
449:デフォルトの名無しさん
06/06/14 19:36:55
トレイが使えるようになる。
Desktop#browse, mail, edit, open, printなどができた。
450:デフォルトの名無しさん
06/06/14 19:40:37
レンダリングに関しては別にって感じですか。
まあそれらの機能だけでも十分かもしれませんね。
451:デフォルトの名無しさん
06/06/14 20:06:43
>>449
全部 AWT の機能だけど。
452:デフォルトの名無しさん
06/06/14 21:00:43
Genericsとかの話用にスレ立てた。
何かすっきりしないと思ったんだよね。
現世代Javaの動向 1
ｽﾚﾘﾝｸ(tech板)
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
ｽﾚﾘﾝｸ(tech板)
はどうすんだって話はあるけど、ま、Mustangリリース後は、
ここがDolphinの話題になって、現世代にMustangが含まれる、でいいかと思って
453:デフォルトの名無しさん
06/06/14 21:13:48
>>447
フォントのAAがヒントに従ってかかるようになった。
5のswing.aatext=trueのように、UI Gothicにまでかかることはなく、tahomaなんかには
なにもしなくてもAAがかかる。
454:デフォルトの名無しさん
06/06/14 21:24:23
( ﾟдﾟ)､AAだと!
455:デフォルトの名無しさん
06/06/14 21:28:53
>>453
ビットマップ情報使えるサイズの場合はアンチエイリアスかからないだけなんでは？
456:デフォルトの名無しさん
06/06/14 23:31:36
個人的にはAAはどうでもいいかな。
browseとトレイはありがたいね
457:デフォルトの名無しさん
06/06/15 11:50:22
>>452
スレ違いを文句いいながら、板違いのスレ建てるわけか。
458:デフォルトの名無しさん
06/06/15 14:13:46
無駄に重複してるだけに見えるがな
459:デフォルトの名無しさん
06/06/15 23:07:20
一時的なスレ違いのために、永続的な重複スレを建てるヤツ
460:デフォルトの名無しさん
06/06/16 10:08:20
たいてい重複スレのほうが長生きするんだよね。レスがないから。
461:デフォルトの名無しさん
06/06/17 00:01:52
Mustang beta2
URLﾘﾝｸ(java.sun.com)
Top 10 Things You Need to Know
1. Web Services
簡単にWebService書けるようになってな、アノテーションで簡単やねん
2. Scripting
PythonとかRubyとか使えるし、みんな使えよ
3. Database
JDKにApacheDerby入るで。@Query(sql="select * from user")とかのアノテーションでSQL埋め込めるし。
4. More Desktop APIs
沢山デスクトップ用改良入ったから期待しとけよ。
JTableとかソートとかフィルタとかできんねよ、すごいやろ？
5. Monitoring and Management
何も考えんでもモニタとかできるようになったで。
Jhatっちゅうヒープ分析ツールも入れといたさかいにあんじょう使うてや。
6. Compiler Access
JSPとかPHP作る人には便利になったやろうなぁ。うごいとる時にコードの
コンパイル動的してJavaCodeにできるんや。
7. Pluggable Annotations
アノテーション自分で付けれるようになってみんなニコニコだお（ ＾ω＾）
8. Desktop Deployment
GUI綺麗に簡単になったで。まぁそれはそのゴニョゴニョや。
9. Security
XML署名とか入ったり、セキュリティの管理簡単になったの。
10. The -ilities: Quality, Compatibility, Stability
まぁ、なんや、みんな、これまで通りよろしゅうな
462:デフォルトの名無しさん
06/06/17 00:28:51
VMで動いてるんだからVMwareみたいにSuspend/Resumeできればいいのに
463:デフォルトの名無しさん
06/06/17 07:03:58
>JDKにApacheDerby入るで。
うわぁマジで？俺も使ってるけど標準はやりすぎだろ…
HSQLのが速いし組み込む目的ならこっち
464:デフォルトの名無しさん
06/06/17 07:20:30
HSQLDBは、通らないSQLが多いからなぁ。
まあ、IBMの政治力の勝利ってことでしょう。
DB2互換だし。
465:デフォルトの名無しさん
06/06/17 07:22:48
Apache Derbyじゃなくて「Java DB」が組み込まれるということになってるけどね。
NetBeans5.5のメニューが「Derby DB」から「Java DB」に変わったときから気になってた。
466:デフォルトの名無しさん
06/06/17 07:25:44
DerbyといえどSQL92に完全準拠してるわけではないよな
JVMのベンダー互換が崩れるきっかけになりそうでやだな
JDOQLだかに準拠させる規格でもあるのかな
467:デフォルトの名無しさん
06/06/17 08:09:14
JDOはもう死んでるでしょ。
それを言うならJPQL(旧EJB-QL)かな。
IBMの意図はわかるけど、Sunの意図がわからない。
468:デフォルトの名無しさん
06/06/17 10:05:42
PersistenceAPIのためだろ
469:デフォルトの名無しさん
06/06/17 10:44:55
OJB＆Derbyで標準化して、実際使うときはHibernate＆HSQLにするということだね
470:デフォルトの名無しさん
06/06/17 10:51:17
HSQLDBはスタンドアロン用だからな
まったくターゲットが違うしJDBCドライバサポートが1.0レベルだったようなきが
HSQLDBの後継のやつはシンプルさが失われてるらしいのがちと心配
スタンドアロンアプリで付属DBとしてならHSQLDBのほうが楽かと
Windowsの業務系スタンドアロンパッケージのほとんどがMSDE使ってるのと同じような感じで
あちらは将来MSSQL鯖にかえるのが目的にもなってるが
471:デフォルトの名無しさん
06/06/17 13:38:37
Mustang b88
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(www.java.net)
MSVC 2005 Expressでのビルドエラーが解消されている。
只でビルド環境そろえられるって素晴らしい。
日本語ドキュメントのレビューがしたい方はこちら
URLﾘﾝｸ(jdk-api-ja.dev.java.net)
472:デフォルトの名無しさん
06/06/18 12:58:55
>>471
俺は、
> 6382711JComboBox incorrectly rendered with alternate WinXP theme
がうれしい。
473:デフォルトの名無しさん
06/06/18 20:27:38
>>461
> 1. Web Services
> 簡単にWebService書けるようになってな、アノテーションで簡単やねん
Java EE絡みのものがなぜかJava SEでできると？
> 3. Database
> JDKにApacheDerby入るで。@Query(sql="select * from user")とかのアノテーションでSQL埋め込めるし。
これは凄い。なんでHSQLDBじゃなかったんだろう。
機能性の高さからかな？ 採用されたのは背後でIBMの関与でもあったのかな？
Appletからメモリ上にテーブルを作成してクエリ呼び出すようなことできるのかな？
> 9. Security
> XML署名とか入ったり、セキュリティの管理簡単になったの。
簡単になるのか。Javaのポリシーファイルはなんだかイマイチだったのか
嬉しいかも。
署名がXMLってどういうこと？ genkeyで作るものはバイナリでは？
ポリシーファイルがXMLになるだけ？
474:デフォルトの名無しさん
06/06/18 20:28:51
>>466
> DerbyといえどSQL92に完全準拠してるわけではないよな
> JVMのベンダー互換が崩れるきっかけになりそうでやだな
そのうちSQL92互換になってゆくのではないかと。
SQL99互換になればいいんだけどねえ
475:デフォルトの名無しさん
06/06/18 20:43:02
Mustangｇが出たとき、
HSQLDBを搭載しているJBossはどのような動きを
示すのか？
HSQLDBをJBossから外してゆくのかな？
476:デフォルトの名無しさん
06/06/18 20:46:49
BEAは面白くないだろうなJava6シリーズは。
477:デフォルトの名無しさん
06/06/18 21:04:14
>>473
XML署名ってRFC3075のことでしょ。
URLﾘﾝｸ(www.w3.org)
URLﾘﾝｸ(www.ietf.org)
この辺り、XMLで統一的に扱えるように。
URLﾘﾝｸ(www.w3.org)
URLﾘﾝｸ(www.w3.org)
URLﾘﾝｸ(www.w3.org)
URLﾘﾝｸ(www.w3.org)
478:デフォルトの名無しさん
06/06/19 00:58:30
>>473
SEでWEBサービスが、というのはクライアントの話だろ？
JDBCやRMI、クライアントのソケットと同じでは？
479:デフォルトの名無しさん
06/06/20 12:55:00
XMLパージングとJavaオブジェクトマッピングを、
アノテーションを使って簡単に。ってことみたいだな。
今時クライアントサイドでも色々やりたいしな。
480:デフォルトの名無しさん
06/07/02 18:41:14
Bata2 に ApacheDerby って入ってるの？
インストールしてみたけど、
どこにあってどう使うのかがわからん。
481:デフォルトの名無しさん
06/07/02 19:42:57
>>480
さぁ？アレ適当に訳したから。
原文は、
final Mustang development kit(JDKだね) will(だからまだかも) co-bundle....
ってなってるからまだ入ってないかもよ。
482:デフォルトの名無しさん
06/07/02 20:00:33
URLﾘﾝｸ(www.javalobby.org)
β２ってb84だったような・・・
483:デフォルトの名無しさん
06/07/02 22:15:01
URLﾘﾝｸ(journal.mycom.co.jp)
の辺りの記事では
Beta2 に入ってるっぽく書いてあるんだけど、
URLﾘﾝｸ(www.in-vitro.jp)
のように
%JAVA_HOME%/db
には入ってなかった
484:デフォルトの名無しさん
06/07/03 01:10:44
せっかくweekly buildされてんだから、β２にこだわらず、最新build使うってのがいーんじゃない？
485:デフォルトの名無しさん
06/07/03 02:50:44
b90 のインストールに失敗するんだよね
「変換するときにエラーが発生しました。
指定された変換のパスが有効であることを確認してください」とかいわれる。
jdk-6-rc-bin-b90-windows-i586-30_jun_2006.exe って奴を
3回落としてきてるんだけど、3回とも同じメッセージが出て駄目だった。
b89 だったらインストールできるんだけど。
486:デフォルトの名無しさん
06/07/03 03:10:10
>>485
漏れも出る。
インストーラのアイコンも変わってるし、
何か派手な事またしてんのかなーっと思って、b89入れ直しました
487:デフォルトの名無しさん
06/07/04 09:31:22
b90でRhino削除されてないか？
488:デフォルトの名無しさん
06/07/04 20:51:34
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所 所沢（池袋・高田馬場から直通）
よろしくおねがいします
ｉ－ｗａｎｔ－ｔｏ－ｓｔｕｄｙ－ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
489:デフォルトの名無しさん
06/07/05 02:20:38
コンビニのバイトより安いですが、よろしくお願いします。
490:デフォルトの名無しさん
06/07/05 02:42:38
この時給って事は、その分、生徒が夏帆みたいな子なんだよな？
491:デフォルトの名無しさん
06/07/07 20:39:21
URLﾘﾝｸ(jdk-api-ja.dev.java.net) で
APIドキュメントの翻訳進行中
492:デフォルトの名無しさん
06/07/12 00:26:45
b90でコケて(?)以来、snapshotがとまったな。
493:デフォルトの名無しさん
06/07/12 02:29:38
>>492
いや、forumではannualだからビルドねーよ、とのこと
SUNWは７月から会計年度始まるからな
494:デフォルトの名無しさん
06/07/12 03:01:13
>>492
> There won't be a promoted build on July 6th because of 4th-of-July holidays. [July 3, 2006]
495:デフォルトの名無しさん
06/07/12 08:41:36
>>490
所沢に行くとチーマーに拉致監禁されて
出会い系サイト作らされてｒｙ
496:デフォルトの名無しさん
06/07/12 09:46:35
>>488-489
なんだその安すぎる時給は。なめとんのかｺﾞﾙｧ！
時給5000円以上じゃないと絶対に引き受けない。
497:デフォルトの名無しさん
06/07/12 10:12:48
>>496
毎回手作りケーキと紅茶が付くとしても？
498:デフォルトの名無しさん
06/07/12 10:14:23
>>497
だれの手作りかによる
まずは写真とプロフィール（略
499:デフォルトの名無しさん
06/07/12 10:37:40
>>497
割に合わんな。毎日同じもん食っても飽きる。
毎日中華丼やキムチ食わされたらさすがにキレる。
そんな子供だましなことに乗せられる騙される奴は餓鬼や新人や新卒くらい。
そんな給料で結婚子育て生活ができるとでも思っているのか！！！！！！！！！！！！
二人の子どもを大学院に行かせる金も用意できないだろがゴルァ！
授業料がいくらかかると思っているのか貴様！
ケーキが100円、紅茶が150円だとして、時給1000円
だとしても、
一日8時間勤務だとしたら、日給8250円相当にしかならない。
500:デフォルトの名無しさん
06/07/12 17:52:25
>>499より>>498に賛同する。
人間、夢を持てよ。
501:デフォルトの名無しさん
06/07/12 17:59:56
>>499
ケーキが欲しいんじゃない、人はケーキの向こう側に夢を見るんだよ
502:デフォルトの名無しさん
06/07/12 18:18:09
>>499
> ケーキが100円
「手作り」ということを忘れている。Priceless