- 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の動向 ２
pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/
- 116 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 18:17:37 ]
- もうHaskell風に(\s1,s2 -> s1.compreToIgnoreCase(s2))でいいよ
Stringくらい型推論しろ
- 117 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 18:32:46 ]
- そうか、そうだな。時間かけて話し合えば良い物できるできるというものでもなかったな。
声のでかい順に嗜好を取り込んだ最小公倍数的仕様が最良になるとは思わないし。
逆にセンスのある一人の天才が作った方がシンプルで良い。
- 118 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 18:39:00 ]
- >>116
C#でも仮引数型の型推論してくれたような。
- 119 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 18:43:23 ]
- 仮引数型の型推論は、後付けで導入できるんだったら後回しでもいいような気もする。
他の部分で型推論を導入する際の一貫性みたいなもんもあるし。
- 120 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 21:54:02 ]
- Javaもサーバだけじゃなく一般的になってきて、変なのまでJavaを使うようになってしまったんだな。
変な奴やC#かC++に行ってくれ。
- 121 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 22:09:26 ]
- >>120
さようなら、変な人。。
- 122 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 22:26:23 ]
- 順調にJavaも巨大になってきてるね。
まあいじくられる対象ってのはそういうもんだよね。
- 123 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 22:32:44 ]
- ただ大勢で規格を開発された言語ってのは、
あまりいい感じにならないんだな。
PL/1, Ada, Common Lispなど。
規格管理だけならいいんだけど。
- 124 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 23:28:46 ]
- そりゃこういう連中は総じて自分の業績と功名心の下心でやってるんだから仕方がない。
スタンダードさえ勝ち取れば、中身が多少糞なのは 「解釈の問題」 とでも言っておけば
後世まで評価されると言うことを彼らはよく知っている。
- 125 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 09:54:54 ]
- >>123
重要ところが抜けているけど、javaは規格じゃなくてあくまで企業やjavaを活用する団体が管理している。
ISOとか関係ないから、それでは例えが悪くそもそもそれらの言語とは比べられない。
おまえは言語使用とライブラリは分離されているとか、そんなところも見えてないだろｗ
- 126 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 10:29:22 ]
- （ ﾟдﾟ）ﾎﾟｶｰﾝ
- 127 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 20:15:06 ]
- >>126
大事なところ指摘してるのが分からないんだね。低脳さんｗ
- 128 名前：デフォルトの名無しさん [2008/02/15(金) 20:26:54 ]
- 悪いが俺も >>125 は勝手に話を広げてるようにしか見えないわけだが。
- 129 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 20:40:23 ]
- 規格(standard)ではなく仕様(specification)と言えというのならまだわかる。
- 130 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 21:29:54 ]
- 話は変わるがJavaはSEやEEにどの機能を入れるかというJSRがあるのがいいな。
EE6の場合だとこれだけの機能を追加するのにいくらかかるという資産までしてるみたいだし。
- 131 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 21:35:36 ]
- 資産(asset)ではなく試算(trial calculation)と言えというのならまだわかる。
- 132 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:31:20 ]
- 揚げ足鳥ってこういうことになっていつも非生産的な行為でしかない。非生産的なジャヴァ言語と同じ。
- 133 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:31:55 ]
- なんというこじ付け
- 134 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:41:16 ]
- >>129
>>123-127のレスには「仕様」のことは触れてないようだが、
どこからそんな指摘が出来るんだ？
ところで英語で言えばカッコいいなどと思ってるなら考え直した方がいいだろう。
- 135 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:42:51 ]
- もちろん英語はできるんですよね？
- 136 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:44:42 ]
- >>125みたいな変人はどこにでもいるから。
- 137 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:52:25 ]
- とっても口惜しそうだねｗ
- 138 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:53:55 ]
- 若干一名な。
- 139 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:54:09 ]
- （´･∀･`）ﾀﾞﾖﾈｰ
- 140 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:56:46 ]
- くだらないことをいつまでも続けるのがねらーの悪いとこだな
アダルトチルドレンが多すぎ（古館的な意味で）
- 141 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:58:12 ]
- ↑アダルトチルドレン（古館的意味）とは、正しくおまえのことだな
- 142 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 23:59:39 ]
- クロージャーの議論で、ゴズリンは愚痴ってるけどでもやる気みたいだけど、結局クロージャはどうなるの？
- 143 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:02:17 ]
- >>141
こういうループ野郎がねらーそのもの
- 144 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:03:49 ]
- （´･∀･`）ﾀﾞﾖﾈｰ
- 145 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:10:54 ]
- 若干一名って、おまえの思い込みなだけじゃないのかｗ
- 146 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:17:17 ]
- （´･∀･`）ﾀﾞﾖﾈｰ
- 147 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:18:37 ]
- とっても口くやしそうなのが若干一名います。
- 148 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:23:00 ]
- （´･∀･`）
- 149 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:24:20 ]
- （´･A･`）ﾀﾞﾖﾈｰ
- 150 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:27:54 ]
- >>125の人気に嫉妬。
>>142
ゴスちゃん一人がそんな影響力あるわけじゃないから。
言語開発者であった初期だけでなく、
Javaの方向性に大きな影響を与えたけど、
もうそろそろいいでしょ。
- 151 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:30:28 ]
- >>142
派閥が出来てる状態で言語仕様に深く関わる機能を盛り込めはしないでしょう。
てかサーフィンしてたらSE7にEJB3が追加されるってブログを見つけた。
Webサービスじゃなくて何故にEJB？
- 152 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:54:37 ]
- というか、いまどき「サーフィンｗ」ってなに？
- 153 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 00:56:18 ]
- また沸いてら
- 154 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 01:10:52 ]
- >>151
クロージャに限定すれば、BGGAとかの派閥といってもクロージャの書き方というかリテラルが少し違う程度だろ。
Genericsのようにどこまでテンプレート・プログラムを認めるかと同様に、
クロージャをどこまで広げるかの考え方はあるだろう。
しかし、それを議論していても結局は内部クラス（匿名クラス）でいいのかの議論に戻ってしまうし
とすれば、派閥とかいってもリテラルが簡単か否かの違いでしかない。
それとゴズリン（のUNIXでの貢献も含めて）のそのセンス自体がそのままJavaの思想やセンスになっていると思うんだが？
C#はたいした手間でもないのに何でもリテラルして言語仕様にしたりするけど、正直キモイ。
やっぱりMSはいつまでもハンガリアンだしｗ
- 155 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 01:15:32 ]
- 派閥まで出来とるのか。
ブラウザで踊ってるデューク見て感動していた頃の古き良き時代が懐かしい。
- 156 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 01:20:22 ]
- Javapolis(source)の調査結果は賛否両論であった。
30人の参加者はCICEに賛成し、
BGGA/FCM+JCAは２４人の賛成を得た。
そして、19人が変更しないことを選 んだ。
www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java
- 157 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 02:25:40 ]
- そのは記事以前も見た気がするけど、記事の本人（外人）自体が「Javaらしさ」を
追求しすぎてバイアスがかかってるってことに気がついてない。
クロージャの話なのにScalaとか勧めてるし、多分バカなんだろ。
クロージャってのは中途半端な内部クラスの設計を、さらに拡張して完成させる程度でしかないだろうな。
C++のtemplateかと思ってたらgenericsは思ってたのと全然違ってたし、
クロージャもアレコレ議論するのはオープンでイイが、同じくそんな感じに落ち着くんじゃないか？
うまくいけばゴズリンが大好きなemacs lispにまでもっていければってところ。
- 158 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 02:28:00 ]
- もういっそヒアテキストで他言語埋め込めるようにすりゃ全て解決するだろ。
- 159 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 02:52:13 ]
- char c= "abc".charAt(1);
int z= {int x, int y => x+y}.invoke(2,3);
で、BGGAはStringリテラルと似たようなもの。
CICEは匿名クラスが少し短縮してある程度でしかない。
new Thread(new Runnable() {
public void run() {foo();}
}).start();
new Thread(Runnable(){ foo(); }).start();
- 160 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 02:53:10 ]
- >>158
全くイメージできないんだけど、どういうこと？
- 161 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 02:58:08 ]
- どちらにせよライブラリレベルじゃ不都合だったり出来なかったことが
可能になるわけじゃないから、匿名内部クラスを普通に使ってる人間には
言語汚染にしか見えんのー。
- 162 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 03:04:54 ]
- >>157
Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahe の４人が
進めている下記のクロージャ仕様(BGGA)ならまともなものだと思うぞ。
www.javac.info/closures-v04.html
これがjava7の仕様の一部となることを願うんだ！
- 163 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 03:07:36 ]
- int x = (Integer)new Function("JavaScript", "alert('hello, world');return 100;").exec();
とかで十分だと思うんだ俺…
- 164 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 05:18:51 ]
- 別にｲﾗﾈｰ気もするんだが、自分がいる間に目玉商品機能を作りたいもんなんかね、中の人的には。
- 165 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 08:45:46 ]
- 要るわ。>>162がいい。
- 166 名前：デフォルトの名無しさん [2008/02/16(土) 12:26:06 ]
- そろそろLegacyJavaとか言って1.4をメンテし始めて欲しいのだが
- 167 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 12:29:51 ]
- >>163
それは、普通に使われるとセキュリティーに穴が開くからヤバイと思う。
- 168 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 12:48:06 ]
- Java 6 からは Scripting API というものがあってだな（ｒｙ
- 169 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 13:33:31 ]
- finalと匿名クラスのシンタックスシュガーを用意するだけだよね？
foreachみたいに特定のインタフェースを持ったオブジェクトに適用されるような。
そうなるとJVMがインタフェースを登録するタイミングが気になる。
JEEでClassNotFoundExceptionをやらかす人を増やす仕様だったらどうしよう。
何百個というインタフェースをjava.lang.closureに放り込んで
ブーストラップクラスローダーでロードさせとくとかそういう仕様？
- 170 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 14:47:57 ]
- クロージャをイベント処理とかでよく使う匿名クラスの延長と見るか、
全く新しいパラダイムと見るかじゃないか？
全く新しいといいつつも、
{void => void} .equals( new java.lang.Function() {
public void invoke(){}
}
と同じことを仕様として入れたいのだろうけど。（多分）
内部クラスあるけど、GUIだといつも使うし<... onclick="callback()"> のように書ければいいよねだろ。
大元の発想は。
"abc".equals(new String("abc"))
と同程度なことが実現できるメソッド・バージョン。
クロージャを何に活用するかは議論してるみたいだし、知らん。
- 171 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 15:08:49 ]
- >>168
Java 6が出た当初はjsとの連携なんていらんだろと思ってたけど、最近はjsがお気に入り☆
java.nio とか当初はjava.ioあるし、いらんと思ってたけど、これもなかなか。
内部クラスあるし今はクロージャなんて全くいらんとかかも知れんが、クロージャも同じく「なかなか」になるのかと思う。
- 172 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 15:42:56 ]
- リリース予定は今年でおｋ？
- 173 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 15:46:38 ]
- JSRが提出されるのはSE7のが先じゃないの？
BGGAもv0.5とかなってるし、間に合わない気が
- 174 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 22:42:22 ]
- まったくクロージャを策定するのは苦労じゃ。
- 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 ]
- 追加はしてくれるけど、消したり隠したりしてくれないんだよな。
|
 |
