[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]

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


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

1 名前：デフォルトの名無しさん mailto:sage [2006/11/20(月) 10:38:16 ]: 前スレ

[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/

2006年12月にMustang Java SE 6がリリース予定

Mustangの掲げる主な目標は以下の点にある。
* 互換性と安定性および品質の向上
* Easy of Developmentの実現
* WebサービスおよびXMLサポート機能の拡張
* リソース管理や診断機能の強化
* デスクトップ環境の強化

Java SE 6 じゃじゃ馬ならし
www.javainthebox.net/laboratory/JavaSE6/
730 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 23:21:52 ]: あるBeanのプロパティ値ともうひとつのプロパティ値を足し算してその結果を格納とかめんどくさすぎ
同様にBigDecimalの演算もきっつい
731 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 00:51:51 ]: >>730
プロパティに足し算して格納とかってそんなに使う？
俺、WEB開発系がメインだけど、プロパティに対して加算とかって
ほとんどしたことないし、BigDecimalも使ったことない。

きっとプロパティが必要な分野と、たいして必要とされない分野があるんだろうな。
732 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 01:17:10 ]: getHoge()がめんどくさいから->でやらせろって言ってる人は、
やっぱりadd()がめんどくさいから演算子オーバーロード使わせろ
とか言うのかな。
733 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 02:00:33 ]: BigDecimalは業務系はこれしか使わないというくらい使う
BigDecimalだけはStringのようにシンタックスシュガーとしてaddとかやってほしいな

プロパティの足し算引き算ってのは普通にあるっしょ
金額とか在庫とかいくらでも
特にO/RマッパやBeanBinding関係使うと頻発
734 名前：しろうと mailto:sage [2007/03/20(火) 09:36:43 ]: public class Foo {
　　public int bar;
}

じゃだめなん？
735 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 10:15:22 ]: セット時やゲット時に加工が出来ないからダメ
それに定義のほうはどうにでもなるためたぶん問題になってない
736 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:24:23 ]: VMがグリッドコンピュータに対応するのはいつだ？
737 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:34:18 ]: VMがグリッドコンピュータのネイティブな基盤になればいいのに。
738 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:38:44 ]: 設定がないと動かないJVMは面倒だな。

グリッドとかは、アプリケーションの下で何らかのグリッド制御部が
動いていて、JVMのリソースとしてグリッドが見えるって前提だろうから
MVMが実現して、アプリケーションの起動とJVMの起動が分離するまでは
あんまり興味がないね。
739 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 23:23:42 ]: クラスタ用OSとしてのJVMなら
BEAだかが仮想化技術として構想を発表してたはず
740 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 23:27:12 ]: >>738
グリッドが見えるのを前提にする必要はないでしょう。
HotSpotが全自動で動的最適化を行うように
グリッド制御部が全自動でスレッド分散を行うのが
あるべき姿だと思います。
741 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 22:20:18 ]: JDK7 build10
download.java.net/jdk7/changes/jdk7-b10.html
download.java.net/jdk7/binaries/

NewFeatureは地味なパフォーマンス向上と
getAsText,setAsTextか。これはちょっと嬉しいな。
742 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 05:37:51 ]: グリッドより先にjavacがメニーコアをフルに使用するための中間コード
を生成することになることが重要。
PGがthreadを手書きしてでしか対応できないというのではコストがかかりすぎる。
743 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 13:15:00 ]: プロパティの話に戻りますが、
やっぱ、何か明示的にプロパティを示す構文がほしい。
と思ったのは、eclipseでリファクタリングするとき。
getter側をリネームしたら、setter側も変わってほしいし、名前の定数も変わってほしい。

public static final string PROPNAME_XXX = "XXX";
public Object getXXX() { ... }
public void setXXX() { ... }
の三者の一貫性を、自動的に保ちたい。
なんか、アノテーションつけとくと、eclipseが、それをヒントに一括リネームしてくれる
だけでもいいんだけど。
744 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:16:16 ]: それはプロパティ構文あってもなくてもあんまり変わらないのでは。
745 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:25:33 ]: >>743
getter/setter はまだしも、
> public static final string PROPNAME_XXX = "XXX";
の必要性が良く分からん。
746 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:42:25 ]: 俺もその部分が？だな
名前だけで型がないし、そもそも型が要らないならenumでいいし
まさか、文字列の中身がクラス名とか
747 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 15:40:52 ]: >>745
>>746
プロパティ名を変えるときに、プロパティ名の文字列リテラルがソース中に散らばってると、
修正がめんどくさいから。
IDEの完全一致文字列リテラルの置換でできなくはないけど、"item"、"count"なんてプロパティ名
だと、無関係な文字列に誤爆するかもしれん。
748 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 17:01:43 ]: >>747

＞修正がめんどくさいから。

得てしてこういう理由で出てくるワークアラウンドは
引きずらない方がいい悪習慣である可能性が高い
749 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 18:19:33 ]: >>748
いや、一つの識別子をソース中に書くのは1回で、あとは参照に置き換えるってのは、
コードのメンテナンス性を保つ上で、ものすごく基本的なことだと思うが。

getXXX, setXXXというメソッド名は、XXXというプロパティ名に従属する識別子なんだから、
ソース中の1箇所の変更で、全てが整合性を保った状態で変更されるのが理想。
C#では、それを文法で強制している。javaでは、整合性の保持はプログラマ任せ。
プロパティ名変更する度に、getXXX、setXXX、firePropertyChangeの引数、全て変更って、
バカバカし過ぎる。せめて、IDEに面倒みてもらいたい。
YYYListener、addYYYListener、removeYYYListenerも、相互に関連する名前なんだから、
ソース1箇所の変更で全てが修正される方が望ましい。
これも、C#ではeventで実現できるが、javaはプログラマ任せ。

javaは保たれるべき一貫性の保持を、文法で強制するんじゃなくて、守るべき
ルールとして与えてるだけなんで、そのルールが守られることのチェックを、アノテーションでできてほしい。
addYYYListenerにしても、
@AddListenerMethodFor(YYYListener.class)
void addYYYListener(YYYListener listener) {}
みたいにして、名前の整合性がなかったら、コンパイラで検出できるようにすべきだと思う。
IDEではYYYListenerをリファクタリングでリネームしたら、addもremoveもリネームできて、ほしい。

javaは、識別子の命名ルール関係で、コンパイラでは検出できないけど、
守られていないと正しく動作しない決め事が結構ある。
そのあたり、アノテーションでバンバン検出できるようになると良いんだけど。
750 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:16:31 ]: C#は詳しくないが、プロパティ名を変更したとき、
そのプロパティを実際に使用している箇所の変更は不要なの？
751 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:26:01 ]: private int myVar;
public int MyProperty {
get { return myVar; }
set { myVar = value; }
}
752 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 21:00:03 ]: >>749
> getXXX, setXXXというメソッド名は、XXXというプロパティ名に従属する識別子なんだから、
これも別の概念なんだよね。BeanInfo や PropertyDescriptor を自分で書いてる人は
hoge って名前のプロパティで、void hoge(Object) を setter に、Object hoge() を getter に指定する事も出来るし。
もっとも、真面目に BeanInfo 見てないフレームワークだとプロパティと認識してくれないかもしれんけど。

> バカバカし過ぎる。せめて、IDEに面倒みてもらいたい。
ここは同意なんだけど、IDEで吸収するのか、言語/コンパイラで吸収するのかってのもあるし。
とりあえず、現状だと言語/コンパイラのレベルで BeanInfo 扱うのは面倒っぽい。

例えば、今コンパイルしようとしてる Hoge.java の BeanInfo を扱うのが面倒。
PropertyDescriptor の getWriteMethod とか getReadMethod とかで、
まだコンパイルされてない Hoge.class の java.lang.reflect.Method 取るっても取れないだろうし。
これがないと、プロパティ名を getter/setter に変換できないし。
753 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:03:02 ]: >>747
それはわかるが>>743のコードはカス
>>751のようにすべきかと
754 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:15:07 ]: >>743
PROPNAME_XXX って firePropertyChange 関連以外で使う？
755 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:48:38 ]: >>751
C#構文をそのまま持ち込んだらこうなるな。
欲を言えば、myVarとMyPropertyの関係(というか変数実体についての記述)を
何らかの形で示すことができて、省略時はデフォルトsetter/getterが呼ばれる
ようにできたらとC#より便利になると思うんだけどね。
つまり、アクセスをフックしたり禁止したりする場合だけ明示的に記述する。
＃C#の場合はgetter/setterを省略した場合はアクセス不可
756 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 00:42:52 ]: プロパティと変数なんて一対一になるとは限らないじゃん。
757 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 01:14:48 ]: もちろん絶対必要というわけじゃなくて、プロパティの型と同じ、実体となる
フィールドを指定すること*も*できるってんならいいんじゃない？
758 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 08:18:58 ]: プロパティなんぞいらん。糖文増やしてどうすんだよ。
759 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 12:29:55 ]: >>751みたいなので普通にいいんじゃね？
getとsetのメソッドやら先頭を大文字推奨、プロパティとしては小文字扱いとか
現状のほうがややこしいだろ
getとsetがばらばらにおかれることによって見通しが悪くなる場合もあるし
リファクタリングの問題もある

プロパティ名としてマルチバイトキャラ埋め込んだ場合の話とかもあるし

現状のままが最悪だよ
760 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 13:44:08 ]: >>751
そっから .NET に倣って、 set_プロパティ名 get_プロパティ名ってメソッドに展開される、と？
761 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 02:49:13 ]: private int myVar;
public get int myProperty() {return myVar;}
public set void myProperty(int value) {myVar = value;}

JavaScriptライクにこれでおｋ。
762 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:11:32 ]: getとsetを予約語にせずに実現できるならね。
763 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:31:48 ]: 予約語にしたらまずいん?
764 名前：デフォルトの名無しさん [2007/03/30(金) 05:45:23 ]: getやsetを変数名とかに使ってたらどうするんだよ？
765 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:49:20 ]: そんなに互換が大事ならシンタックスシュガーなんていらないだろｗ
むしろIDEに機能として組み込めよ
766 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 07:07:49 ]: >>764
5.0になったときも非互換変更あったじゃん
そのためにコンパイラの文法バージョンを指定するオプションがあるんでしょ
767 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 07:33:32 ]: @prop(setter="on",getter="on")
private String str;
で
XX.setStr("A");
XX.getStr();
がコンパイルとおる、でなにがいかんのかと（ry
768 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 09:52:12 ]: >>764
@Set、@Getにすればいいよ。
769 名前：デフォルトの名無しさん [2007/03/30(金) 11:45:38 ]: ブロックにアノテーションつけられないんじゃないっけ
770 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 11:54:29 ]: @getter("getValue");
@setter("setValue");
private String value;

これでいーよ。
771 名前：デフォルトの名無しさん [2007/03/30(金) 11:56:08 ]: ブロックとは？
772 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 12:12:16 ]: objective-pascal 方式

@setter("__value") @getter("__value") public String value;
private String __value;
773 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 14:36:20 ]: >>761
に一票。
assertだって使ってた奴いたんだから構わんよ。
というか、get、setっていう変数はなさそうだし、あとに何も付かないset,getメソッドも
そんなに無いだろうからいいよ、それで。
774 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 14:55:04 ]: >>763
予約語にしたら set get が変数名、フィールド名、メソッド名、クラス名等々に使えなくなる。

>>773
java.util.List#get(int) java.util.List#set(int, E)
java.util.Map#get(Object)
これだけあれば影響力十分だよなぁ……
いくら互換性を軽視したって言っても、流石にシャレにならんと思うぞ。

俺なら >>761 の文法なら予約語にしない方を選ぶけど。
ってか、そもそも >>761 って set get つける必要あるのか？
775 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 19:29:56 ]: >>751
のほうがまとまってていいな
776 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 19:35:36 ]: 新記法のプロパティ定義は使い勝手が良くないから駄目だって、
説明の下手なおじさんが上の方で散々教えてくれてるのに。
777 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 21:55:01 ]: >>751みたいなC#方式はvalueが予約語になるのが個人的には嫌だ。
778 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:12:44 ]: >>777
C# みたいな文脈依存の予約語なら、value が使えないのは set {} 内だけだし。
779 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:32:27 ]: 別にそのままにしてなくてもいいだろ
private int myVar;
public int MyProperty(value) {
get { return myVar; }
set { myVar = value; }
}
とか
780 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:45:47 ]: > public int MyProperty(value) {
……。そっちに付けるか
781 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 23:50:18 ]: こんな案もあるんだから、もっとアノテーション使いまくりでいいんじゃねぇの？
今のアノテーション仕様にとらわれる必要はないよ。
journal.mycom.co.jp/articles/2006/11/01/jsr308/
782 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:02:40 ]: アノテーションでコンパイル制御できるようにならんかのう。
ディレクティブは邪道だから駄目か
783 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:50:04 ]: >>776
説明だけが下手なんだったら良かったが、論理展開も
おそらく頭の中も下手だったからな。
784 名前：デフォルトの名無しさん [2007/03/31(土) 06:33:25 ]: 日本語でおｋ
785 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:08:46 ]: >>779
これ今の文法だとgetの後に;が無いって怒られるじゃない
普通のメソッドの中でも {}　でスコープを制限する記法があるから
やっぱ普通のメソッドじゃないという何らかの記述は必要。

>>751 に加えてsetの後に引数記述付けたらいいんじゃないか？

で、この書き方の場合はアノテーションじゃなくて
propertyとかいう新しい予約語使うのがいいな。
メソッドは文法が違うんだから。

アノテーションは、あくまで付加的な情報であって
文法の指定であって欲しくはない。
786 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 11:32:15 ]: >>782

コンパイル制御させたら地獄のIFDEFの復活になりそうなんだが…。
787 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 12:43:15 ]: >>786
でも C# には ConditionalAttribute あるよ
788 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:54:10 ]: >>785
プロパティ構文実装しようとしてる時点で
現行の文法でとおらないというのは意味のないことだな

propertyの予約語に関しては影響範囲はたぶんenumよりは少ないと思う
enumはつかわれまくってたからなぁ
789 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:09:44 ]: >>787
過去の言語を十分に研究して作成した言語でも言語設計の失敗はある。
790 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:13:51 ]: C♯には #if もあるわけで
791 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:55:34 ]: >>785 >>788
ちっとは勉強した方が……

blogs.sun.com/ahe/entry/java_se_7_wish_list
の Shorthand syntax for declaring properties のところに、
この構文なら property はキーワードにする必要が無いって書いてある。

weblogs.java.net/blog/forax/archive/2007/01/a_property_prop_1.html
の prototype-1.7-b05.jar 試してみれば分かるけど
property を言語全体に影響する予約語にする事無く、property でプロパティの定義させてる。

常に予約語にする必要がないってわけじゃないけど、
導入する構文によっては予約語にする必要はない。
もしくは、予約語にしないように導入する構文を慎重に決める必要がある。
792 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:00:14 ]: 予約語にしたほうが構文解析が楽とか紛らわしいのがなくなるとかメリットもあるから
単純にはいえんよ
793 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:17:48 ]: >>789
なんか一言で失敗作呼ばわりされてしまったなぁｗ
794 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:40:08 ]: >>792
「property を予約語にしない」ってのを選択肢として持ってないのは不勉強。
795 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:58:51 ]: 勉強厨か
上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ
gotoだって使わないが予約語だし、newだって予約語にしなくても本当は使えることは使える
796 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 18:01:38 ]: > 上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ
既出。
797 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:18:57 ]: >>796
「既出。」だけのレスは2ch不勉強
798 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 23:32:26 ]: propertyっていう変数は、結構使われてると思うけどな。
799 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 11:57:31 ]: >>792
紛らわしさって？

property を予約語にしない場合の紛らわしさって言っても
せいぜい property property が出来るぐらいだと思うが。
800 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:05:25 ]: ×property property が出来る
○class property がある時に property property property が出来る

もっとも、>>785 も >>788 も具体的な構文規則も例も書いてないから、
>>785 >>788 の脳内構文で出来るのかは知らんけど。
801 名前：デフォルトの名無しさん [2007/04/01(日) 15:41:45 ]: >>781
前にGenerics使うと長くなるからtypedefいるだろとか言ってたC++信者がいたが
これはほんとに可読性に問題起こしそうだな……
どうにかならんもんか
802 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 15:52:49 ]: >>801
blogs.sun.com/ahe/entry/java_se_7_wish_list

Type aliasing
Shorthand syntax for declaring local variables
803 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:57:04 ]: >>802
結局は、独自定義があるとそれによって可読性が落ちるかもしれないから
適用範囲に十分注意ってとこだな
804 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:00:26 ]: Ada風に別名を付けるときに元の型から値の有効範囲縛れるように出来ると良いな。

新しい型の有効範囲外だとエラー投げてほしい。

typedef month byte 1...12;

aliasでも良いね。...は->でも良いかも。

alias day byte 1->31;
typedef leapsecond byte 1->60;

キャストは値の範囲が大きい方から小さい方の場合は代入されている値が小さい方で表せる範囲の場合のみ、または小さい方から大きい方。
805 名前：デフォルトの名無しさん [2007/04/01(日) 18:12:17 ]: >>804
それこそアノテーションでいいんじゃないか？
806 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:34:49 ]: >804
飽和演算もほしくなるな
807 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:52:21 ]: JavaBeansのフィールドやセッターにアノテーションってのが現実的だな
範囲外がきたとき例外出すのか、飽和させるのか、値を変えないのかの判断もいれればグッド
ついでに一番面倒なプロパティリスナのfireも自動でやってほしい
808 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 21:53:14 ]: >>807
その情報を元にWebアプリ側で自動でバリデートやエラーメッセージ出してくれたら最高に楽だな。
809 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:05:41 ]: >>808
なんかライブラリとNetBeansでプラグイン作りたくなってきた
GUIとのバインディングでもかなり効率よさそうだしな
810 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:41:26 ]: プロパティなど要らぬ！
構文糖・即・悪こそが我々Java厨の共有する唯一の正義ではなかったのか！

それを捨てるというならば、まずtypedefを導入しやがれ
811 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:14:33 ]: Genericsは構文糖じゃねーのかよ
生成されるバイトコードはキャスト使いまくりのものと同じだろ
812 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:28:04 ]: >>810
そんなもん、EoD とか言って autoboxing みたいな構文糖が入った時点で捨てとるような。
813 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 00:10:56 ]: >>811
乙
814 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 11:11:13 ]: >>810
何かいまいち語呂が悪いな

というかtyprdefはねえよwww
815 名前：デフォルトの名無しさん [2007/04/03(火) 19:05:07 ]: そろそろCloneable（何故かスペルミス）が@SafeCloneアノテーションになったりしないかな
ある程度どのように実装しているか表現できればコードチェックのときに便利だと思う。

copy(Cloneable obj)とかif(obj instanceof Cloneable){/*処理*/}とかそういうことは出来なくなるけど……
816 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 19:40:24 ]: いやtypedefは欲しい。
Javaで導入されていないのは、sourceが読みにくくなるという理由だろうけど。
817 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:04:57 ]: typedef String MyString;
みたいなのは同じ型の別名を作るだけだから有害だが、
typedef Map<String, List<MyClass<Integer, String>>> MyType;
みたいなのは特別な組み合わせに特別な名前をつけているから有用だと思う。

だから、Genericsありの場合のみtypedefを許すというのはどうだろうか。
818 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:12:11 ]: class MyType extends Map<String, List<MyClass<Integer, String>>>{}
819 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:31:09 ]: >>816
実態が変わるのならきっついのでは？
Javaはすべてダイナミックリンクなわけで
Stringからchar[]への変更とかIntegerからLongへの変更とか現実的ではないし
820 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:38:01 ]: これさー

typedef String MyString;
MyString abc = "sample";

これ、OK にするん？　NG にするん？
821 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:44:12 ]: >>818
それでいけるかー

typedefのためだけにファイルいっこつくるのが許容できるかどうかだな
822 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:51:09 ]: >>821
逆にファイル一個作らない場合、どのソースファイルに記述するか迷わないか？
ひとつのクラス内でのみ使用するというならいいが。
823 名前：デフォルトの名無しさん [2007/04/03(火) 21:53:30 ]: >>818
擬似Typedefアンチパターン
www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml
824 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:27:37 ]: extendsに関してはあまり的を得ているとはいえない批判だな。
公開APIで使うべきではないけど、内部処理で使うには問題はなかろう。
「大規模では・・・」というのも、モジュール境界で使わなければいいだろう。
825 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:33:36 ]: >> 820
OKだろ。
826 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:59:03 ]: >824
当を得る、的を射ると書こうと思ったが
"的を得る"もあながち間違いとはいえないらしい
827 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 23:09:14 ]: >>820
そんなん言語仕様作ってる連中が居るところで聞かなきゃ意味がない。

どーせやるなら generics のパラメタ型だけじゃなくて
JSR 308 の型へのアノテーションも含めて欲しいけど。
828 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 23:35:42 ]: typedef派の諸君！ Java7で何かが変わると思ったら大間違いだ！
所詮dolphinなんか、property派のお祭に過ぎない！
我々typedef派にとってdolphinほど馬鹿馬鹿しいものはない！
多数決で決めれば、property派が勝つに決まってるじゃないか！
829 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:16:01 ]: 俺は言語使用云々よりもMVMが最も重要だと思う。
MVMさえ実現されれば、デスクトップJavaもサーバJavaもかなりの勢いで道が開ける。
830 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:44:35 ]: 俺もそうは思うが、MVMって実装される予定はあるのか？

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

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