[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 13:54 / Filesize : 204 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん [2008/01/03(木) 12:29:37 ]
前スレ

[Java SE 7] 次世代Javaの動向 5 [dolphin]
pc11.2ch.net/test/read.cgi/tech/1178925915

[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
pc11.2ch.net/test/read.cgi/tech/1163986696/

[mustang] 次世代Javaの動向 3 [dolphin]
pc8.2ch.net/test/read.cgi/tech/1157227790/

次世代Javaの動向 2
pc8.2ch.net/test/read.cgi/tech/1147881822/

【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/

175 名前:デフォルトの名無しさん mailto:sage [2008/02/16(土) 22:46:25 ]
そうだね

176 名前:デフォルトの名無しさん mailto:sage [2008/02/16(土) 23:07:33 ]
____               CICE版
|← reject|   BGGAの中の人  Closure   ユーザー
. ̄.|| ̄ ̄        ┗(^o^ )┳(`Д´)┳(^o^ )┛≡=-
  ||            ┏┗   ┗┗  ┏┗ ≡=-
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

177 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:23:23 ]
>>156
www.java.net/pub/pq/196
こっちの投票だと CICE 3.9%、BGGA 42.7%で 10倍も差がついてる。
javapolisだと、josh blochの公演があったからそれに引きずられたんだろね。
公演前は 2:1 でBGGAの方が投票多かったって書いてあるし。

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

178 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 03:01:15 ]
まあ、長く使わんと手に馴染み具合が分からんですよねぇ

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

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

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

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

179 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 09:10:53 ]
ARMよりは、BGGAのcontrol invocation syntax使える方が嬉しいけど。
ARMってjava.io.Closeableとか、java.util.concurrent.locks.Lockとか
特定のinterface実装してないと使えないみたいだし。

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

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

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

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

181 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 23:02:49 ]
匿名クラスと比べてみたら、新しい

182 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 23:07:22 ]
内部匿名クラスは、やっぱりjdk1.0のイベント処理方法の不満から解決策として出てきたんだし、
匿名クラスの設計(や表記方法)が中途半端というのはよく分かる。
本心としては、昔は急いでたから匿名・関数生成リテラルまで設計してなかったこと
についての後始末ってとこなんじゃないか?

183 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 23:20:19 ]
でもたいして変わらないものにしかならなさそうなんだけど。



184 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 23:33:17 ]
そもそもクロージャ自体「使わなくてもいい便利なもの」扱いしてる時点で「匿名クラスと大して変わらないもの」あつかいされるのは仕方ないんじゃないか。
匿名クラスのシンタックスシュガーレベルの扱いじゃなくて、通常のメソッドがクロージャの簡易構文になってるぐらいでないと意味ない気がする。


185 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 00:18:33 ]
>>182
匿名クラスの設計も表記方法も完成されてると思うよ。
単にタイプ数が多くなるから面倒くさいだけで。

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

186 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 07:18:15 ]
匿名クラスは匿名クラスでいいが、
クラスである必要のないところにはクロージャを使いたい。
クラス至上主義は要らない。関数は関数だ。

187 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 07:21:55 ]
匿名内部クラスより (数値の上でだけでも) パフォーマンスが良いとかあればまだ良いんだけどね。

188 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 10:28:49 ]
それが無いと困る場合というのが明確でない機能は
追加せんでもいいと思うんだが。
ジェネリクスやプロパティまでは理解できたが、
クロージャは必要性がよくわからんな。

189 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 14:09:45 ]
JDK1.6のコンカレント関連のFeature<T>とか見たときに、いい加減第一級の関数型なしに匿名クラスでエミュレーションするのは苦しいだろうと思ったのだが、おまえらはどうだ?


190 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 14:27:15 ]
もう JCP は勝手に別の言語でも作っててもらいたいんだが。

191 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 14:33:28 ]
>>189
禿同。
何でもクラスと言われたSmalltalkより酷いことになってる。
まさにクラス馬鹿一代。> Java

192 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 14:44:48 ]
>>189
苦しいというほど頻繁に使われるシーンが思い浮かばない。
Threadとかもあるし、俺はこの程度なら言語仕様を汚してまで
導入する意義は薄いと思うな。

193 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 14:49:35 ]
汚れない



194 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 15:54:36 ]
>>189
Future<V>はクラスで適切だと思うけど。
Callable<V>インターフェイスを実装した匿名クラスを書くのが面倒なので
クロージャ使わせろという話と勘違いしていない?

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

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

195 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:06:07 ]
> あと、BGGAの block.invoke(args) って記法を block(args) って書けるように
おれもして欲しい。

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

196 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:13:21 ]
>>192
ぶっちゃけ、プロパティ導入の方が言語仕様が汚れる。
>>195の反対の理屈で、いままでメソッドだったものが
フィールド/変数の名前空間使うことになるから。

197 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:27:53 ]
プロパティはほんと汚れるって感じするわ。便利だけどw

198 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:33:31 ]
プロパティがないとRADサポートできない。

199 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:47:13 ]
「どっちがより汚いか」なんて議論しても意味ねーw
新しい表記、文法の導入はどっちにしても「汚れる」ことに変わりない。
重要なのはそれを許容するだけのメリットがあるかどうか。

200 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:50:42 ]
クロージャでもBGGAの場合は、RAIIっぽい事ができるってメリットあるけど、
プロパティは基本的にタイプ数が減るだけ。

201 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:52:58 ]
>>199
汚れる程度の問題もあるんだよ。
プロパティ導入は下手するとソース互換性破壊するし。

202 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:53:53 ]
コンポーネント志向にはプロパティが必要。

203 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 16:55:26 ]
beansのプロパティで我慢



204 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 17:07:46 ]
>>201
バイナリ互換性じゃなくてソース互換性?
「下手すると」って書いてるけど、どの案でどういう問題が?

205 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 18:03:08 ]
>>204
あるクラスにプロパティ hoge と、フィールド hoge があった時に、
識別子 hoge で、フィールドとプロパティどっちアクセスすんの?って話。

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

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

206 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 18:26:02 ]
排他にすりゃいいし、フィールドで隠蔽できないようにすりゃいい。
というか、draft3はそういう案じゃなかったか?

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

207 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 18:30:18 ]
>>206
標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。
beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。

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

208 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 19:00:33 ]
これね。
docs.google.com/View?docid=dfhbvdfw_1f7mzf2

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

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

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

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

209 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 19:48:02 ]
>>208
自前のクラスで、標準APIのクラス Hoge を継承する SubHoge に、
フィールド hoge が宣言されてるとする。
これは既存のソースでプロパティ導入前にはなんの問題もないけど、
プロパティが導入されて、標準APIのクラス Hoge にプロパティ hoge が後付で導入され、
おまけにプロパティとフィールドが排他だとなると、ソース互換性が破壊されるわけ。

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

210 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 19:59:01 ]
標準API :
class Hoge{ abstract Hoge getHoge(); }
ユーザ側:
class SubHoge extends Hoge{
 Hoge hoge;
 Hoge getHoge(){ return hoge; }
}
で上手くいってたのに、
プロパティ導入して、標準APIが
class Hoge {
 abstract Hoge getHoge();
 abstract property Hoge hoge;
}
とかに変わると、SubHoge はコンパイル通らなくなるわな。

211 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:04:42 ]
後付けでプロパティ追加なんてしなきゃいいじゃん。
これができないとどういう場合に困るの?

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

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

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

213 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:33:45 ]
みんなきちんとIntrospectorを使っているんならまだましだけど、
勝手にやっちゃってるフレームワークが氾濫しているのも問題だよな。



214 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:41:35 ]
今時プロパティのない言語は時代遅れ。

215 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:44:49 ]
get/setをエディタが補う時代にプロパティとかいらんだろ
でもプロパティってバインド機能があるんだっけか

216 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:48:48 ]
追加はしてくれるけど、消したり隠したりしてくれないんだよな。

217 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 21:27:05 ]
正直クロージャすらない言語は時代遅れ

218 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:29:55 ]
func.invoke(20)をfunc(20)にするのだけど、確かに見た目と意味が一致していい気がするけど、

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

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

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

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


219 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:34:53 ]
そんな使い方しないってw
あほかよ

220 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:44:47 ]
int x = (Integer)new Function("text/javascript", "1+1").invole();

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

221 名前:デフォルトの名無しさん [2008/02/24(日) 22:45:52 ]
タプルと演算子オーバーロードは、確か、絶対にサポートしないってどこか書いてあった(英語)。
bigdecimalのオペレータ[+,*とか]・オーバーロード・サポートもあんまり期待できない。

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

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

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



222 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:49:53 ]
演算子オーバーロードのサポートも時間の問題と思われ

223 名前:デフォルトの名無しさん [2008/02/24(日) 22:53:26 ]
それと、クラスをメモリ上に一旦読み込んでしまえば、
匿名クラスとかクロージャとかで関数一つでもクラスをいちいち生成される
とか気にしても、性能に全く関係ないよ。

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

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

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



224 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:56:34 ]
>>220
それ、何をしたいのかやりたいことは分かるが、そもそもJavaと関係ないだろw

225 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:06:29 ]
>>217
匿名クラスがjavaのクロージャなんだけど、
そのクロージャってなんだよw

226 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:09:26 ]
java.util.concurrent
GUI使わない案件なら、やっぱりJavaはこれでしょ。
クロージャのほうが先に導入されてるとそれなりに面白かったけど。

227 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:14:33 ]
>>225
匿名クラスがクロージャそのものなのはC#なんでは?

228 名前:デフォルトの名無しさん [2008/02/24(日) 23:15:46 ]
>>220
それだけダラダラとタイプ量があるなら匿名クラスと同じ。
ていうか、匿名クラスならまだjavaだけど、それjsだろ。
いつも書いてて絶対に必要になるし、ダラダラ書くの面倒じゃん?ってのが始まりだろう。

229 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:17:51 ]
>>218
俺には「C言語はアセンブリのマクロにすぎないから不要」ってぐらい暴論に聞こえるんだが。
クロージャにしたって、一塊の処理の手続きを「ひとつのオブジェクトでもある」のと「データとは異なるものとしてコンパイラに特別扱いしてもらう」のうち後者以外はすべて異端って扱いはどうなのよ。

230 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:24:33 ]
>>227
C#のクロージャの話をしたいのか。


231 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:26:33 ]
>>229
なかなかの暴論だなw
オレには「アセンブリは、所詮はCのベンダー実装に過ぎない」って思ってたけどw

232 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:27:24 ]
withLock(lock, {=>
System.out.println("hello");
});
withLock(lock) {
System.out.println("hello");
}
あたりは本当にいろいろと可能性が広がりそうで楽しみ。

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

233 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:28:04 ]
>>230
C#スレでやれよ。



234 名前:デフォルトの名無しさん [2008/02/24(日) 23:30:08 ]
>>229
何を実現したいのかと、それをどうやるのかの実装とは、別にして考えてみたらどうだ?
それなら全て異端ってことじゃなく、両立可能だろうな。

235 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:38:09 ]
>>232
Collectionには手を出さないんじゃないか?
ジネリクスと混じってしまってパッと見なんだか分からなくなる。
ジネリクスは目が慣れるまで少し時間がかかったしw
コンカレント辺りのブロッキングキュー・クラスとかでやるならまだしも。

236 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:40:35 ]
俺はGenericsは単純すぎて拍子抜けした。
C++使いからみれば単純この上ない。

237 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:54:25 ]
C++が意味不明なんだよ。
それもジェネリクスじゃなくて、C++はテンプレートだろ。
C++のやりたいことは雛形プログラム手法で、Java総称型なんだけど、その様子だと分かってないな。

238 名前:デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:59:23 ]
>>220
それ、クロージャじゃなくてevalじゃん。

239 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:02:44 ]
ちなみにおまいらクロージャ候補はどの候補がいいと思うよ?


240 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:10:35 ]
>>238
クロージャーであることが目的になっちゃってるの?

241 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:13:49 ]
>>240
evalだと静的に色々解析できないじゃん

242 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:20:02 ]
内部イテレータが欲しい俺は少数派か?

243 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:23:33 ]
↑具体的にどういうコードになるの?



244 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:24:35 ]
>>240
少なくともevalを多用するのは嫌い。
evalは(たとえ動的言語であっても)最後の武器だと思ってる。


245 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:25:11 ]
2ch は保守派 (というか優位に立ちたい人) しかいないからわざわざ披露しない方が良いよ。

246 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:30:15 ]
html出身の人にはクロージャの意味は分からんのです。

247 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:39:00 ]
>>237
C++の方が機能が多いってだけだろ。
C++だってgenericだぜ。

248 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:39:47 ]
>>245
馬鹿は頭固いから何言ってもダメだしな。
なぜこんなスレに来ているのかわからんが。

249 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 01:02:42 ]
JavaのGenericsを批判している人も批判していない人も、型引数への制約やワイルドカード型引数といった
JavaのGenericsの機能を本当に使いこなせている?

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

250 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 01:08:50 ]
あの程度理解できない人間はこのスレに来るべきじゃないよ

251 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 01:21:01 ]
clone() じゃねーけど、減らす仕様もロードマップに示して欲しいなー。
@Deprecated じゃないけど 「旧仕様互換ソースはコンパイルできるが新仕様準拠ソースは
コンパイルエラー/ただしランタイムは解決可能」 みたいなアノテーションでも作って。

252 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 01:37:26 ]
それはコンパイルオプションで解決すりゃいいことでは

253 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 04:54:50 ]
使う方のソースはそれで良いけど宣言する方のソースはアノテーション必要でしょ。



254 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 05:55:52 ]
やっぱりC++出身者は、個人的な問題を指摘する事が多いね。

255 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 09:14:43 ]
cloneって何か変わるの??

256 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 14:10:28 ]
>>245
だれだおまえ?

257 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 21:27:34 ]
私の名はクリストファー・エリクソン。

258 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 21:28:14 ]
よう!くりちゃん!!久しぶり!!

259 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 22:15:22 ]
>>250
ずいぶんと自信過剰ですな。
ところでJVMの実装とかあなたはできるんですか?

260 名前:デフォルトの名無しさん mailto:sage [2008/02/25(月) 23:09:49 ]
>>222
おまえはだれだ?

261 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 00:19:24 ]
ボクハ、オンガクカ、デンタクカタテニ

262 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 00:28:42 ]
もうjava2Kでいいじゃん

263 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 00:46:08 ]
>>259
GenericsとJVM実装って全然別やん…



264 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 00:55:26 ]
なんか、味噌でも糞でもとにかく延々と追加して行かなければいけないような雰囲気だねー。
マッチポンプで仕事作ってるようも見える。

265 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 02:46:25 ]
C#がね。

266 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 02:51:58 ]
clone()ってなくなるの?

267 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 07:47:39 ]
珍妙なもんを削る方向にも進めということでしょ。

268 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 09:27:53 ]
チンチンを削ちゃうの?

269 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 09:27:55 ]
>>266
今更削除できないと思うが。

270 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 09:47:04 ]
clone削除されたら困るんだが

271 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 10:05:15 ]
されないw

272 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 11:57:23 ]
やっぱり小さいチンチンは削除です

273 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 14:30:54 ]
>>245
全く何を言いたいのか意味不明なんだが、もっと分かりやすく書き直してくれないか?



274 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 20:17:29 ]
>>268
尖らすの?

275 名前:デフォルトの名無しさん mailto:sage [2008/02/26(火) 23:06:10 ]
ちぎり取るんだろ






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<204KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef