- 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/
- 684 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:26:00 ]
- >>683
△既存の interface -> ○標準APIの既存の interface
- 685 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:10:18 ]
- java.sql.Connectionなんか増えまくりだった気がするが。
古い実装のを呼ぼうとするとErrorでも出るかな
- 686 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:11:37 ]
- >>683
既存のinterfaceを安易に拡張できないってのは当然だね。
>既存の interface 経由で使えない事が予想される新プロパティは
なんで新プロパティに限って既存のinterface経由で使われることを
期待されなければならないんだろう？
- 687 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:16:08 ]
- >>682
> だから標準APIに「抽象メソッド」は追加できない
> ↓
> 「抽象メソッド」は標準APIに使えないから無意味
ここで飛躍してる。基本的には「追加できない」==「使えない」とはならない。
で、setter/getter とは無関係な新プロパティシステムを導入したとして、
その新プロパティを、標準APIの既存の interface で使いたいと言う場合は
・新プロパティを追加すれば、その interface を実装していたコードを変更する必要が出る。
・逆に新プロパティを追加しなければ、標準APIの既存の interface では新プロパティは使えない
で、俺は標準APIの管理者は後者を選択すると予想するので、
その場合は新プロパティは「標準APIの既存の interface経由では使えない」ので
使えないとか、使い勝手が悪いと言えるだろう。
仮に前者を選んだとしても、コードの変更を迫られるので無問題とはならない。
- 688 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:23:35 ]
- >>686
> なんで新プロパティに限って既存のinterface経由で使われることを
> 期待されなければならないんだろう？
限って？ 他では期待されてないんだっけか？
- 689 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:27:18 ]
- >>688
限ってないよな。Closure だって、Closure Conversion とかで
abstract なメソッドが一つだけの既存の interface に変換する事を考えてたりするし。
- 690 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:48:55 ]
- blogs.sun.com/ahe/entry/java_se_7_wish_list のリストとかを見るに、
たいてい inteface と関係ないか、既存の interface との協調にも配慮してあるよーな。
- 691 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 05:18:23 ]
- >>681
新世代・・・・ああああNewGeneration用のGCってことか。
いや、殿堂入りが無いというより、tenureの32をいじれるようになった方がいいかな。
ある程度、コア数が増えて並行処理が速くなると、OldGenerationを少なくして
Newgenerationのtenureを32回より多くして、NewGenerationで運用したほうが
効率いいと思うんよねぇ。
昔、24CPUのマシン使った時、10GB程度のNewGenerationをParNewGCかけてたけど
確か0.5s程、ホンの一瞬だった。
- 692 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 07:42:00 ]
- >>688
class定義に影響する新機能としては例えばfunction-typeなんかがあるけど、
じゃあこれは既存のinterfaceに追加されて使われることを期待されてるの？
- 693 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 08:53:05 ]
- >>688
対抗馬である setter/getter の syntax sugar なプロパティなら
既存の interface経由で使えるしな。
それと比較しても 「使い勝手が悪い」といえるだろうね。
- 694 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 08:53:44 ]
- >>692
具体的に、どんな問題が出るんだ？
- 695 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 12:35:00 ]
- >>691
並列GCはデフォの状態よりスループットはいいけどレスポンスが大幅に悪化するぞ
あとGC稼動のタイミングをコントロールできる10msのGCとコントロールできない0.1msのGCだと前者のほうがいいわけで
- 696 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 13:50:53 ]
- >>695
今のマシンスペックならGCに0.1msもかからんよ。
ゲームならヒープサイズとスタックサイズの調整で2Dまでならストレスなく遊べる。
やっぱメモリ食いは収まらないけど。
取り合えずただのデスクトップツールとしては実用的じゃない？
ジョイパッド拾えるようになると同じ方向性で障害者用の入力補助装置の入力拾えそうでアクセシビリティ周りが格段に良くなって良いと思うけどな。
- 697 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 14:15:04 ]
- >>686
GCの時間はヒープサイズに綺麗に比例するのでなんともいえないよ
最近のマシン持っているけど0.5msきることは実際にゲームつくっていてまずない
新世代領域を少なくしてやっと0.2mくらいか
インクリメンタルGC（現在の実装は並列GC）だとレスポンス悪化してるし、
デフォのGCだとFullGCがいつかは必ず起きるし、おきたら使い物にならない
そもそもJava2DやJOGLなどライブラリによるGCはコントロールできなから
自分のコードでの調整は何も意味がない
0.1mが0.05mであっても同じこと
リアルタイム性ってのは早いかどうかじゃなく、コントロールできること、把握できることだから
- 698 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 15:41:40 ]
- >>571
まるでApache Antの記法だな
- 699 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 15:42:31 ]
- >>572
四項演算子か。
Checkstyleプラグインが警告しそうだな
- 700 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 19:54:46 ]
- >>693
既存のinterfaceに public int getHoge(); なんて追加したら
おんなじように「問題」は発生するが？
>>694
何の問題も出ないだろう。既存のinterfaceに追加したりしなけりゃ。
- 701 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 20:14:48 ]
- >>700
setter/getter の syntax sugar なプロパティであれば、
既存の interface で、既に宣言されている setter/getter で
プロパティにアクセスする分には問題は発生しない。
setter/getter と関係のない新プロパティシステムを導入した場合、
既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。
で、標準API みたいに変更すると影響範囲が大きい既存の interface は安易に変更できないから
新プロパティを追加したくても既存の interface には追加できず、
既存の interface からは、この新プロパティは使用できない可能性が高い。
故に setter/getter の syntax sugar よりも 「使い勝手が悪い」といえる。
- 702 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 21:11:41 ]
- 相変わらず説明が下手だな。
- 703 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 21:19:01 ]
- さすがに読解力に問題があるだろう。
- 704 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 22:07:53 ]
- >>701
>既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。
既存の「getter/setter」と関係ないプロパティが前提なら、当然既存のinterfaceにも
存在しているわけがないだろう。ここでアクセスしようとしている「プロパティ」ってのは
何のことを言っているんだ？
もし「getter/setter」のことならば、それはプロパティとは関係のない単なるメソッドだから、
普通にメソッドとしてアクセスすればよい。
もし新たにプロパティを追加することを想定しているのならば、それはインターフェースの
拡張に他ならないから、他に影響が出るのは当然。それは別にプロパティに限らない。
- 705 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 22:18:48 ]
- >>704
> ここでアクセスしようとしている「プロパティ」ってのは
当然、setter/getter と関係ない新プロパティシステムのプロパティ。
で、プロパティの持つものは、既存の setter/getter で表わされるのと同じもの。
プロパティ導入の大きな動機の一つに、setter/getter を宣言するのも、
呼び出すのも冗長だという不満を解消するというものがある。
setter/gettter とは別の新プロパティシステムを使えば、
既存の interface にある、既存の JavaBeans のプロパティに対して、
setter/getter を呼び出すのが冗長だという不満を解消できない。
仮に Tiger で追加された Generics が、もし仮に既存の Collection API と協調できず、
List でも Map でもパラメタ型を取れなければ、使い勝手が悪いと評価されるだろう。
それと同じ。
- 706 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:00:03 ]
- あはははは。
foo.getBar()がfoo->barになっただけでどんな不満が解消するんだよ。
- 707 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:07:26 ]
- 流れぶったぎるがJSR-296使ってみた奴居る？
- 708 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:08:42 ]
- >>706
なら、なんでプロパティが必要なんだ？
それに、最初出てきた案は setter/getter の syntax sugar なんだぜ？
- 709 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:18:32 ]
- >>703
わかってもらえない場合は、別の角度からの説明を試みるべきだと思う。
>>706
だよな。いらねーよな、こんなプロパティもどき。初心者が混乱するだけ。
- 710 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:22:40 ]
- >>709
普通は説明されなくてもわかるだろ。あんなの。
気づかない方が頭がおかしいんだよ。
- 711 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:35:01 ]
- >>710
「普通」とか言うけど、「使い勝手が悪い」っていう結論は主観が入り込んでるだろ？
- 712 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:10:42 ]
- ->で全然問題なし
- 713 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:25:29 ]
- JavaBeans のプロパティと同名のフィールドを持てる事が問題ってところから
>>621 で
> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決する
という意見が出た。
新プロパティシステムを作れば、フィールドと同名のプロパティを禁止できるからって話なんだろうけど、
>>674 のような問題も予想されるため、完全な解決とはならない。
結局、限定名のルールとかフィールドアクセスのルールが
ぎちぎちに詰め込まれているので dot でフィールドにアクセスする事と、
dot でプロパティにアクセスする事が相容れないと考えた方が良いみたい。
それとは別に、>>640、>>641 で言ったように setter/getter とは別の新プロパティシステムを導入する場合、
setter/getter の syntax sugar ならプロパティとしてアクセスできた情報の一部に
プロパティシステムを使ってアクセスできない事が予想される。
結局、「setter/getter とは別の新プロパティシステム」を導入しても
setter/getter のsyntax sugar で問題とされた事を解決できず、
さらに setter/getter の syntax sugar では出なかった問題も発生する。
まぁ、「setter/getter とは別の新プロパティシステム」の詳細を見ての評価じゃないけど
現在の情報からなら setter/getter の syntax sugar より「使い勝手が悪い」と言える。
- 714 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:28:20 ]
- >>713
どうでもいーけど長文ウザイ
- 715 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:20:14 ]
- 説明が下手なんだからしょうがないよ。
- 716 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:22:41 ]
- 説明されなくたって、既存のプログラムに新機能を追加して、
どんな影響が出るかを予見できないってのは技術者として拙いだろ。
- 717 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:30:57 ]
- じゃあレスする必要ないじゃんｗ
なんで一生懸命説明してんの？
- 718 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:33:03 ]
- >>716-717
次世代Javaと関係ない話題だな。 続きは他所行ってやれ。
- 719 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 12:59:19 ]
- >>718
たった2レス程度で…気が短いな
- 720 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 16:16:28 ]
- >>713
結局、getHoge()/setHoge()を使わない新プロパティシステムを導入しても、
既存のgetHoge()/setHoge()を使えないから使い勝手が悪いということかw
- 721 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:14:19 ]
- ふー、びっくりした。でも、反対派の意見はほぼ一点に集中している。
プロパティは既存の言語機能と干渉するから、導入の必要はないというもの。
それ、ほんとなのかなあ（ｒｙ
- 722 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:44:26 ]
- サイレントマジョリティの声を尊重してプロパティを導入することにしました。
当然のことだよね
- 723 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:51:13 ]
- >>721
既存の言語機能と干渉とかいう以前に、そもそも「そんなに必要な物なのか」って
ことがまずあるんじゃないか？
プロパティの仕組み導入の話が出てるのは、
「定義するのも使うのも既存のgetter/setterの仕組みだとめんどくさい」
という要望から来てるんだろうけど、
「めんどくさい」っていう理由だけで言語仕様変えてったらとんでもないことになる気がする。
相当面倒、ってのが、すごく簡単ってなるならまだ納得できなくもないけど、
IDE使ってる人の中にはgetter/setterがそこまで面倒とは思わない人もいるんじゃないかとも思う
ちなみに個人的にはgetter/setterの使用側は今のままで十分。
ただ、定義するのが面倒だから、アノテーションとかで自動でデフォルトのgetter/setterが
作成される仕組みができるぐらいでも満足だよ。
- 724 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 02:14:53 ]
- a = obj get foo;
obj set foo = 1;
- 725 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:54:34 ]
- >>722
>>667 の結果を見るに、
プロパティ要らないって意見の方が サイレントマジョリティで、
プロパティ欲しいと言ってる方が、声の大きい少数派。
- 726 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 11:47:22 ]
- >>721-722はネタなんで相手しなくていいです
- 727 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 12:23:09 ]
- >>724 はネタじゃないのか……
- 728 名前：724 mailto:sage [2007/03/19(月) 20:34:17 ]
- >>727
ネタです。
- 729 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 23:15:19 ]
- >>723
うむ。
プロパティ自体は特にそんなに欲しいものでもないが、自分で開発していて
コードの半分以上が意味のないgetter/setterで占められているクラスが
山のようにあるのを見ると、何かが間違ってる気がしてならない.。
- 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 ]
- 日本語でおｋ
|
 |
