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

[mustang/Java SE 6] ..

656:デフォルトの名無しさん
07/03/15 00:00:24
耐えられないなら++も--も使わずにプログラムを書いてくれ。

657:デフォルトの名無しさん
07/03/15 00:45:46
// << >> == && ||
↑これらも

つか==なしとか縛りきつくね？

658:デフォルトの名無しさん
07/03/15 00:47:52
VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
FlashのActionScript(ECMAScript派生)もread onlyプロパティがあったが、dotだね。
dot以外を選択するのは、正直コンパイラ屋の都合でしかないと感じる。
メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。

659:デフォルトの名無しさん
07/03/15 01:30:43
ちょっと待てECMAScriptは全部プロパティだ

660:デフォルトの名無しさん
07/03/15 01:32:16
>>656-657
2chらしい模範解答だなｗ

661:デフォルトの名無しさん
07/03/15 01:52:21
IDEやJava用エディタならテンプレート機能が充実しているし
そんな構文糖は要らないってのも意見として尊重してほすぃ。

662:デフォルトの名無しさん
07/03/15 02:15:35
>>661
どうなんだろ、セマンティクスがハッキリするから
getter,setterが分かりやすくなるという点ではIDEも歓迎なのでは？
実現方法はともかく。

663:デフォルトの名無しさん
07/03/15 04:06:26
>>661
コードの読みやすさが上がるのであれば、新しい構文糖の導入も大いに結構じゃないかい？

664:デフォルトの名無しさん
07/03/15 07:43:28
>>651
あきれる。

> 仮に追加しても何の影響もない。
そんなは事ない。

665:デフォルトの名無しさん
07/03/15 07:47:20
>>651
>仮に追加しても何の影響もない。
追加したら、java.beans.DesignTime を実装している既存のクラスを書き換えなきゃいけなくなるだろう。

影響がないって、馬鹿じゃないのか？

666:デフォルトの名無しさん
07/03/15 07:48:08
>>665
× java.beans.DesignTime
○ java.beans.DesignMode

667:デフォルトの名無しさん
07/03/15 08:18:45
>>661
URLﾘﾝｸ(java.net) とか見ると、
property構文は、XML構文に次いで人気がないんだよね。

URLﾘﾝｸ(java.net) とかだと、
very important と、somewhat important をあわせても 1/4 ぐらいだったりする。

まぁ、この手の投票がちゃんと機能してるかはわからんし、
構文糖なら要らないってのと、重要度が低いってのは同じ意見じゃないんだけど。

668:デフォルトの名無しさん
07/03/15 08:34:05
>>658
> VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
もし問題がないなら dot を使うのに反対の人はあんまし居ないと思うんだが。
同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
わかりにくくないって言うんならともかく。

> メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。
それって、何か改善する？

669:デフォルトの名無しさん
07/03/15 09:09:07
>>668
> 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
> わかりにくくないって言うんならともかく。
それなら、同名のフィールドとプロパティが共存できて、
さらにフィールドもプロパティも dot でアクセスする言語がわかりにくくないって言わないと。
（dotじゃなくても良いけど同じ記号でアクセスする言語）

670:デフォルトの名無しさん
07/03/15 09:17:17
>>651
> その例でinterfaceの方にisDesignTime()を
> 追加するという仮定自体がそもそもありえないし
……。 isDesignTime() は元からあるメソッドですが。

671:649
07/03/15 10:23:39
>>670
おまえ逃げてないで俺の質問に答えろよ。

672:デフォルトの名無しさん
07/03/15 10:26:26
>>671
質問になってない。

673:649
07/03/15 10:31:39
>>672
答えになってない。

674:デフォルトの名無しさん
07/03/15 10:36:21
>>621
それだけじゃ解決しないね。

新プロパティ(dotでアクセス)と同名のフィールドが作れるなら
setter/getterのプロパティと同じ問題が起こるし、
C#みたく新プロパティと同名のフィールドが作れなくするなら、
標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。

これ以降は >>640 >>641 と同じ路線だな。
上記の書き換えを最小限に抑えようとすれば、
標準APIは極力新プロパティを追加しない方向になるだろうから、
新プロパティの構文は言語仕様に定義されたが、
標準APIで新プロパティが使えない、という本末転倒な事態が予測される。

つまり、使い勝手が悪い。

675:デフォルトの名無しさん
07/03/15 10:39:07
>標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。
標準APIが新プロパティを追加したら、
そのclass/interfaceを継承/実装して同名のフィールドを使っていたユーザコードの書き換えが必要になる。

676:649
07/03/15 10:42:44
やっとわかったよ。お互い説明が下手だと苦労するなｗ

677:デフォルトの名無しさん
07/03/15 11:02:59
>>675
まぁ、interface に「新プロパティ」を追加したら、
どっちみちそのinterface を実装しているクラスの書き換えが必要になる。
既存のコードは setter/getter は実装してても、
「新プロパティ」まで実装してて書き換えの必要がないってのは考えにくいから。

この書き換えを最小限に抑えようとすれば、
標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
以下、>>674 と同文、と。

678:デフォルトの名無しさん
07/03/15 11:15:13
> 標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
標準API は、既存の setter/getter を置き換えるものも含めて、
極力 abstract な新プロパティを追加しない方向になるだろうから

うーむ。既存の setter/getter は互換性のために残す事を想定してるから
置き換える、じゃないんな。まぁ、setter/getter を残しても残さなくても、
標準API に abstract な新プロパティを追加すれば同じだけど。

679:デフォルトの名無しさん
07/03/15 20:13:04
ゲーム関係に力を入れてけば自然とデスクトップ周りが強化されるからそっち系だな
OSを選ばないUDIライブラリとか、BGM周りはネイティブにディスパッチとかね。
標準であるかどうかってのがここらへんは大きい。

680:デフォルトの名無しさん
07/03/15 22:34:05
まずジョイパットか

681:デフォルトの名無しさん
07/03/15 23:05:33
ジョイパッドサポートは地味に大きいな

って10年前からいわれてるが

あとはJOGLも標準ではいってくれるといいのだが
今はプラットフォームごとに用意してあげないといかんからWindows以外はめんどくさい

本当は新世代専用GCコールもほしい
タイミングコントロールできて殿堂入りしないやつならアクション系もバリバリ使える

682:デフォルトの名無しさん
07/03/16 00:05:01
>>677
interfaceに追加したらそれを実装するクラスに影響があるのは、
「プロパティ」に限らず抽象メソッドでも同じだわな。

既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
↓
だから標準APIに「抽象メソッド」は追加できない
↓
「抽象メソッド」は標準APIに使えないから無意味

あほか。

683:デフォルトの名無しさん
07/03/16 00:22:54
>>682
> 既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
普通は、既存の interface に抽象メソッド追加するのは慎重にする。

逆に、今までにない interface を作る時は自由に抽象メソッドを定義できる。
> 「抽象メソッド」は標準APIに使えないから無意味
安易に追加できないが、「使えない」とか「無意味」とはならない。

abstract な新プロパティも、抽象メソッドと同じで、
今までにない interface を作る場合は自由に定義できるだろうけど、
既存の interface に追加する場合は慎重にならざるを得ないだろう。
既存の interface 経由で使えない事が予想される新プロパティは
「使えない」とか「使い勝手が悪い」と言える。

684:デフォルトの名無しさん
07/03/16 00:26:00
>>683
△既存の interface -> ○標準APIの既存の interface

685:デフォルトの名無しさん
07/03/16 01:10:18
java.sql.Connectionなんか増えまくりだった気がするが。
古い実装のを呼ぼうとするとErrorでも出るかな

686:デフォルトの名無しさん
07/03/16 01:11:37
>>683
既存のinterfaceを安易に拡張できないってのは当然だね。

>既存の interface 経由で使えない事が予想される新プロパティは

なんで新プロパティに限って既存のinterface経由で使われることを
期待されなければならないんだろう？

687:デフォルトの名無しさん
07/03/16 01:16:08
>>682
> だから標準APIに「抽象メソッド」は追加できない
> ↓
> 「抽象メソッド」は標準APIに使えないから無意味
ここで飛躍してる。基本的には「追加できない」==「使えない」とはならない。

で、setter/getter とは無関係な新プロパティシステムを導入したとして、
その新プロパティを、標準APIの既存の interface で使いたいと言う場合は
・新プロパティを追加すれば、その interface を実装していたコードを変更する必要が出る。
・逆に新プロパティを追加しなければ、標準APIの既存の interface では新プロパティは使えない

で、俺は標準APIの管理者は後者を選択すると予想するので、
その場合は新プロパティは「標準APIの既存の interface経由では使えない」ので
使えないとか、使い勝手が悪いと言えるだろう。
仮に前者を選んだとしても、コードの変更を迫られるので無問題とはならない。

688:デフォルトの名無しさん
07/03/16 01:23:35
>>686
> なんで新プロパティに限って既存のinterface経由で使われることを
> 期待されなければならないんだろう？
限って？他では期待されてないんだっけか？

689:デフォルトの名無しさん
07/03/16 01:27:18
>>688
限ってないよな。Closure だって、Closure Conversion とかで
abstract なメソッドが一つだけの既存の interface に変換する事を考えてたりするし。

690:デフォルトの名無しさん
07/03/16 01:48:55
URLﾘﾝｸ(blogs.sun.com) のリストとかを見るに、
たいてい inteface と関係ないか、既存の interface との協調にも配慮してあるよーな。

691:デフォルトの名無しさん
07/03/16 05:18:23
>>681
新世代・・・・ああああNewGeneration用のGCってことか。
いや、殿堂入りが無いというより、tenureの32をいじれるようになった方がいいかな。

ある程度、コア数が増えて並行処理が速くなると、OldGenerationを少なくして
Newgenerationのtenureを32回より多くして、NewGenerationで運用したほうが
効率いいと思うんよねぇ。
昔、24CPUのマシン使った時、10GB程度のNewGenerationをParNewGCかけてたけど
確か0.5s程、ホンの一瞬だった。

692:デフォルトの名無しさん
07/03/16 07:42:00
>>688
class定義に影響する新機能としては例えばfunction-typeなんかがあるけど、
じゃあこれは既存のinterfaceに追加されて使われることを期待されてるの？

693:デフォルトの名無しさん
07/03/16 08:53:05
>>688
対抗馬である setter/getter の syntax sugar なプロパティなら
既存の interface経由で使えるしな。

それと比較しても「使い勝手が悪い」といえるだろうね。

694:デフォルトの名無しさん
07/03/16 08:53:44
>>692
具体的に、どんな問題が出るんだ？

695:デフォルトの名無しさん
07/03/16 12:35:00
>>691
並列GCはデフォの状態よりスループットはいいけどレスポンスが大幅に悪化するぞ
あとGC稼動のタイミングをコントロールできる10msのGCとコントロールできない0.1msのGCだと前者のほうがいいわけで

696:デフォルトの名無しさん
07/03/16 13:50:53
>>695
今のマシンスペックならGCに0.1msもかからんよ。

ゲームならヒープサイズとスタックサイズの調整で2Dまでならストレスなく遊べる。
やっぱメモリ食いは収まらないけど。

取り合えずただのデスクトップツールとしては実用的じゃない？

ジョイパッド拾えるようになると同じ方向性で障害者用の入力補助装置の入力拾えそうでアクセシビリティ周りが格段に良くなって良いと思うけどな。

697:デフォルトの名無しさん
07/03/16 14:15:04
>>686
GCの時間はヒープサイズに綺麗に比例するのでなんともいえないよ

最近のマシン持っているけど0.5msきることは実際にゲームつくっていてまずない
新世代領域を少なくしてやっと0.2mくらいか

インクリメンタルGC（現在の実装は並列GC）だとレスポンス悪化してるし、
デフォのGCだとFullGCがいつかは必ず起きるし、おきたら使い物にならない

そもそもJava2DやJOGLなどライブラリによるGCはコントロールできなから
自分のコードでの調整は何も意味がない

0.1mが0.05mであっても同じこと

リアルタイム性ってのは早いかどうかじゃなく、コントロールできること、把握できることだから

698:デフォルトの名無しさん
07/03/16 15:41:40
>>571
まるでApache Antの記法だな

699:デフォルトの名無しさん
07/03/16 15:42:31
>>572
四項演算子か。

Checkstyleプラグインが警告しそうだな

700:デフォルトの名無しさん
07/03/16 19:54:46
>>693
既存のinterfaceに public int getHoge(); なんて追加したら
おんなじように「問題」は発生するが？

>>694
何の問題も出ないだろう。既存のinterfaceに追加したりしなけりゃ。

701:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/16 21:11:41
相変わらず説明が下手だな。

703:デフォルトの名無しさん
07/03/16 21:19:01
さすがに読解力に問題があるだろう。

704:デフォルトの名無しさん
07/03/16 22:07:53
>>701
>既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。

既存の「getter/setter」と関係ないプロパティが前提なら、当然既存のinterfaceにも
存在しているわけがないだろう。ここでアクセスしようとしている「プロパティ」ってのは
何のことを言っているんだ？
もし「getter/setter」のことならば、それはプロパティとは関係のない単なるメソッドだから、
普通にメソッドとしてアクセスすればよい。
もし新たにプロパティを追加することを想定しているのならば、それはインターフェースの
拡張に他ならないから、他に影響が出るのは当然。それは別にプロパティに限らない。

705:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/16 23:00:03
あはははは。
foo.getBar()がfoo->barになっただけでどんな不満が解消するんだよ。

707:デフォルトの名無しさん
07/03/16 23:07:26
流れぶったぎるがJSR-296使ってみた奴居る？

708:デフォルトの名無しさん
07/03/16 23:08:42
>>706
なら、なんでプロパティが必要なんだ？

それに、最初出てきた案は setter/getter の syntax sugar なんだぜ？

709:デフォルトの名無しさん
07/03/16 23:18:32
>>703
わかってもらえない場合は、別の角度からの説明を試みるべきだと思う。

>>706
だよな。いらねーよな、こんなプロパティもどき。初心者が混乱するだけ。

710:デフォルトの名無しさん
07/03/16 23:22:40
>>709
普通は説明されなくてもわかるだろ。あんなの。
気づかない方が頭がおかしいんだよ。

711:デフォルトの名無しさん
07/03/16 23:35:01
>>710
「普通」とか言うけど、「使い勝手が悪い」っていう結論は主観が入り込んでるだろ？

712:デフォルトの名無しさん
07/03/17 00:10:42
->で全然問題なし

713:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/17 00:28:20
>>713
どうでもいーけど長文ウザイ

715:デフォルトの名無しさん
07/03/17 10:20:14
説明が下手なんだからしょうがないよ。

716:デフォルトの名無しさん
07/03/17 10:22:41
説明されなくたって、既存のプログラムに新機能を追加して、
どんな影響が出るかを予見できないってのは技術者として拙いだろ。

717:デフォルトの名無しさん
07/03/17 10:30:57
じゃあレスする必要ないじゃんｗ
なんで一生懸命説明してんの？

718:デフォルトの名無しさん
07/03/17 10:33:03
>>716-717
次世代Javaと関係ない話題だな。続きは他所行ってやれ。

719:デフォルトの名無しさん
07/03/17 12:59:19
>>718
たった2レス程度で…気が短いな

720:デフォルトの名無しさん
07/03/17 16:16:28
>>713
結局、getHoge()/setHoge()を使わない新プロパティシステムを導入しても、
既存のgetHoge()/setHoge()を使えないから使い勝手が悪いということかw

721:デフォルトの名無しさん
07/03/19 00:14:19
ふー、びっくりした。でも、反対派の意見はほぼ一点に集中している。
プロパティは既存の言語機能と干渉するから、導入の必要はないというもの。
それ、ほんとなのかなあ（ｒｙ

722:デフォルトの名無しさん
07/03/19 00:44:26
サイレントマジョリティの声を尊重してプロパティを導入することにしました。
当然のことだよね

723:デフォルトの名無しさん
07/03/19 00:51:13
>>721
既存の言語機能と干渉とかいう以前に、そもそも「そんなに必要な物なのか」って
ことがまずあるんじゃないか？

プロパティの仕組み導入の話が出てるのは、
「定義するのも使うのも既存のgetter/setterの仕組みだとめんどくさい」
という要望から来てるんだろうけど、
「めんどくさい」っていう理由だけで言語仕様変えてったらとんでもないことになる気がする。

相当面倒、ってのが、すごく簡単ってなるならまだ納得できなくもないけど、
IDE使ってる人の中にはgetter/setterがそこまで面倒とは思わない人もいるんじゃないかとも思う

ちなみに個人的にはgetter/setterの使用側は今のままで十分。
ただ、定義するのが面倒だから、アノテーションとかで自動でデフォルトのgetter/setterが
作成される仕組みができるぐらいでも満足だよ。

724:デフォルトの名無しさん
07/03/19 02:14:53
a　=　obj　get　foo;
obj　set　foo　=　1;

725:デフォルトの名無しさん
07/03/19 08:54:34
>>722
>>667 の結果を見るに、
プロパティ要らないって意見の方がサイレントマジョリティで、
プロパティ欲しいと言ってる方が、声の大きい少数派。

726:デフォルトの名無しさん
07/03/19 11:47:22
>>721-722はネタなんで相手しなくていいです

727:デフォルトの名無しさん
07/03/19 12:23:09
>>724 はネタじゃないのか……

728:724
07/03/19 20:34:17
>>727
ネタです。

729:デフォルトの名無しさん
07/03/19 23:15:19
>>723
うむ。
プロパティ自体は特にそんなに欲しいものでもないが、自分で開発していて
コードの半分以上が意味のないgetter/setterで占められているクラスが
山のようにあるのを見ると、何かが間違ってる気がしてならない.。

730:デフォルトの名無しさん
07/03/19 23:21:52
あるBeanのプロパティ値ともうひとつのプロパティ値を足し算してその結果を格納とかめんどくさすぎ
同様にBigDecimalの演算もきっつい

731:デフォルトの名無しさん
07/03/20 00:51:51
>>730
プロパティに足し算して格納とかってそんなに使う？
俺、WEB開発系がメインだけど、プロパティに対して加算とかって
ほとんどしたことないし、BigDecimalも使ったことない。

きっとプロパティが必要な分野と、たいして必要とされない分野があるんだろうな。

732:デフォルトの名無しさん
07/03/20 01:17:10
getHoge()がめんどくさいから->でやらせろって言ってる人は、
やっぱりadd()がめんどくさいから演算子オーバーロード使わせろ
とか言うのかな。

733:デフォルトの名無しさん
07/03/20 02:00:33
BigDecimalは業務系はこれしか使わないというくらい使う
BigDecimalだけはStringのようにシンタックスシュガーとしてaddとかやってほしいな

プロパティの足し算引き算ってのは普通にあるっしょ
金額とか在庫とかいくらでも
特にO/RマッパやBeanBinding関係使うと頻発

734:しろうと
07/03/20 09:36:43
public class Foo {
　　public int bar;
}

じゃだめなん？

735:デフォルトの名無しさん
07/03/20 10:15:22
セット時やゲット時に加工が出来ないからダメ
それに定義のほうはどうにでもなるためたぶん問題になってない

736:デフォルトの名無しさん
07/03/20 22:24:23
VMがグリッドコンピュータに対応するのはいつだ？

737:デフォルトの名無しさん
07/03/20 22:34:18
VMがグリッドコンピュータのネイティブな基盤になればいいのに。

738:デフォルトの名無しさん
07/03/20 22:38:44
設定がないと動かないJVMは面倒だな。

グリッドとかは、アプリケーションの下で何らかのグリッド制御部が
動いていて、JVMのリソースとしてグリッドが見えるって前提だろうから
MVMが実現して、アプリケーションの起動とJVMの起動が分離するまでは
あんまり興味がないね。

739:デフォルトの名無しさん
07/03/20 23:23:42
クラスタ用OSとしてのJVMなら
BEAだかが仮想化技術として構想を発表してたはず

740:デフォルトの名無しさん
07/03/20 23:27:12
>>738
グリッドが見えるのを前提にする必要はないでしょう。
HotSpotが全自動で動的最適化を行うように
グリッド制御部が全自動でスレッド分散を行うのが
あるべき姿だと思います。

741:デフォルトの名無しさん
07/03/24 22:20:18
JDK7 build10
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

NewFeatureは地味なパフォーマンス向上と
getAsText,setAsTextか。これはちょっと嬉しいな。

742:デフォルトの名無しさん
07/03/25 05:37:51
グリッドより先にjavacがメニーコアをフルに使用するための中間コード
を生成することになることが重要。
PGがthreadを手書きしてでしか対応できないというのではコストがかかりすぎる。

743:デフォルトの名無しさん
07/03/26 13:15:00
プロパティの話に戻りますが、
やっぱ、何か明示的にプロパティを示す構文がほしい。
と思ったのは、eclipseでリファクタリングするとき。
getter側をリネームしたら、setter側も変わってほしいし、名前の定数も変わってほしい。

public static final string PROPNAME_XXX = "XXX";
public Object getXXX() { ... }
public void setXXX() { ... }
の三者の一貫性を、自動的に保ちたい。
なんか、アノテーションつけとくと、eclipseが、それをヒントに一括リネームしてくれる
だけでもいいんだけど。

744:デフォルトの名無しさん
07/03/26 14:16:16
それはプロパティ構文あってもなくてもあんまり変わらないのでは。

745:デフォルトの名無しさん
07/03/26 14:25:33
>>743
getter/setter はまだしも、
> public static final string PROPNAME_XXX = "XXX";
の必要性が良く分からん。

746:デフォルトの名無しさん
07/03/26 14:42:25
俺もその部分が？だな
名前だけで型がないし、そもそも型が要らないならenumでいいし
まさか、文字列の中身がクラス名とか

747:デフォルトの名無しさん
07/03/26 15:40:52
>>745
>>746
プロパティ名を変えるときに、プロパティ名の文字列リテラルがソース中に散らばってると、
修正がめんどくさいから。
IDEの完全一致文字列リテラルの置換でできなくはないけど、"item"、"count"なんてプロパティ名
だと、無関係な文字列に誤爆するかもしれん。

748:デフォルトの名無しさん
07/03/26 17:01:43
>>747

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

得てしてこういう理由で出てくるワークアラウンドは
引きずらない方がいい悪習慣である可能性が高い

749:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/26 19:16:31
C#は詳しくないが、プロパティ名を変更したとき、
そのプロパティを実際に使用している箇所の変更は不要なの？

751:デフォルトの名無しさん
07/03/26 19:26:01
private int myVar;
public int MyProperty {
get { return myVar; }
set { myVar = value; }
}

752:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/26 23:03:02
>>747
それはわかるが>>743のコードはカス
>>751のようにすべきかと

754:デフォルトの名無しさん
07/03/26 23:15:07
>>743
PROPNAME_XXX って firePropertyChange 関連以外で使う？

755:デフォルトの名無しさん
07/03/26 23:48:38
>>751
C#構文をそのまま持ち込んだらこうなるな。
欲を言えば、myVarとMyPropertyの関係(というか変数実体についての記述)を
何らかの形で示すことができて、省略時はデフォルトsetter/getterが呼ばれる
ようにできたらとC#より便利になると思うんだけどね。
つまり、アクセスをフックしたり禁止したりする場合だけ明示的に記述する。
＃C#の場合はgetter/setterを省略した場合はアクセス不可

756:デフォルトの名無しさん
07/03/27 00:42:52
プロパティと変数なんて一対一になるとは限らないじゃん。

757:デフォルトの名無しさん
07/03/27 01:14:48
もちろん絶対必要というわけじゃなくて、プロパティの型と同じ、実体となる
フィールドを指定すること*も*できるってんならいいんじゃない？

758:デフォルトの名無しさん
07/03/27 08:18:58
プロパティなんぞいらん。糖文増やしてどうすんだよ。

759:デフォルトの名無しさん
07/03/27 12:29:55
>>751みたいなので普通にいいんじゃね？
getとsetのメソッドやら先頭を大文字推奨、プロパティとしては小文字扱いとか
現状のほうがややこしいだろ
getとsetがばらばらにおかれることによって見通しが悪くなる場合もあるし
リファクタリングの問題もある

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

現状のままが最悪だよ

760:デフォルトの名無しさん
07/03/27 13:44:08
>>751
そっから .NET に倣って、 set_プロパティ名 get_プロパティ名ってメソッドに展開される、と？

761:デフォルトの名無しさん
07/03/30 02:49:13
private int myVar;
public get int myProperty() {return myVar;}
public set void myProperty(int value) {myVar = value;}

JavaScriptライクにこれでおｋ。

762:デフォルトの名無しさん
07/03/30 05:11:32
getとsetを予約語にせずに実現できるならね。

763:デフォルトの名無しさん
07/03/30 05:31:48
予約語にしたらまずいん?

764:デフォルトの名無しさん
07/03/30 05:45:23
getやsetを変数名とかに使ってたらどうするんだよ？

765:デフォルトの名無しさん
07/03/30 05:49:20
そんなに互換が大事ならシンタックスシュガーなんていらないだろｗ
むしろIDEに機能として組み込めよ

766:デフォルトの名無しさん
07/03/30 07:07:49
>>764
5.0になったときも非互換変更あったじゃん
そのためにコンパイラの文法バージョンを指定するオプションがあるんでしょ

767:デフォルトの名無しさん
07/03/30 07:33:32
@prop(setter="on",getter="on")
private String str;
で
XX.setStr("A");
XX.getStr();
がコンパイルとおる、でなにがいかんのかと（ry

768:デフォルトの名無しさん
07/03/30 09:52:12
>>764
@Set、@Getにすればいいよ。

769:デフォルトの名無しさん
07/03/30 11:45:38
ブロックにアノテーションつけられないんじゃないっけ

770:デフォルトの名無しさん
07/03/30 11:54:29
@getter("getValue");
@setter("setValue");
private　String　value;

これでいーよ。

771:デフォルトの名無しさん
07/03/30 11:56:08
ブロックとは？

772:デフォルトの名無しさん
07/03/30 12:12:16
objective-pascal　方式

@setter("__value")　@getter("__value")　public　String　value;
private　String　__value;

773:デフォルトの名無しさん
07/03/30 14:36:20
>>761
に一票。
assertだって使ってた奴いたんだから構わんよ。
というか、get、setっていう変数はなさそうだし、あとに何も付かないset,getメソッドも
そんなに無いだろうからいいよ、それで。

774:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/30 19:29:56
>>751
のほうがまとまってていいな

776:デフォルトの名無しさん
07/03/30 19:35:36
新記法のプロパティ定義は使い勝手が良くないから駄目だって、
説明の下手なおじさんが上の方で散々教えてくれてるのに。

777:デフォルトの名無しさん
07/03/30 21:55:01
>>751みたいなC#方式はvalueが予約語になるのが個人的には嫌だ。

778:デフォルトの名無しさん
07/03/30 22:12:44
>>777
C# みたいな文脈依存の予約語なら、value が使えないのは set {} 内だけだし。

779:デフォルトの名無しさん
07/03/30 22:32:27
別にそのままにしてなくてもいいだろ
private int myVar;
public int MyProperty(value) {
get { return myVar; }
set { myVar = value; }
}
とか

780:デフォルトの名無しさん
07/03/30 22:45:47
> public int MyProperty(value) {
……。そっちに付けるか

781:デフォルトの名無しさん
07/03/30 23:50:18
こんな案もあるんだから、もっとアノテーション使いまくりでいいんじゃねぇの？
今のアノテーション仕様にとらわれる必要はないよ。
URLﾘﾝｸ(journal.mycom.co.jp)

782:デフォルトの名無しさん
07/03/31 00:02:40
アノテーションでコンパイル制御できるようにならんかのう。
ディレクティブは邪道だから駄目か

783:デフォルトの名無しさん
07/03/31 00:50:04
>>776
説明だけが下手なんだったら良かったが、論理展開も
おそらく頭の中も下手だったからな。

784:デフォルトの名無しさん
07/03/31 06:33:25
日本語でおｋ

785:デフォルトの名無しさん
07/03/31 10:08:46
>>779
これ今の文法だとgetの後に;が無いって怒られるじゃない
普通のメソッドの中でも {}　でスコープを制限する記法があるから
やっぱ普通のメソッドじゃないという何らかの記述は必要。

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

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

アノテーションは、あくまで付加的な情報であって
文法の指定であって欲しくはない。

786:デフォルトの名無しさん
07/03/31 11:32:15
>>782

コンパイル制御させたら地獄のIFDEFの復活になりそうなんだが…。

787:デフォルトの名無しさん
07/03/31 12:43:15
>>786
でも　C#　には　ConditionalAttribute　あるよ

788:デフォルトの名無しさん
07/03/31 13:54:10
>>785
プロパティ構文実装しようとしてる時点で
現行の文法でとおらないというのは意味のないことだな

propertyの予約語に関しては影響範囲はたぶんenumよりは少ないと思う
enumはつかわれまくってたからなぁ

789:デフォルトの名無しさん
07/03/31 16:09:44
>>787
過去の言語を十分に研究して作成した言語でも言語設計の失敗はある。

790:デフォルトの名無しさん
07/03/31 16:13:51
C♯には #if もあるわけで

791:デフォルトの名無しさん
07/03/31 16:55:34
>>785 >>788
ちっとは勉強した方が……

URLﾘﾝｸ(blogs.sun.com)
の Shorthand syntax for declaring properties のところに、
この構文なら property はキーワードにする必要が無いって書いてある。

URLﾘﾝｸ(weblogs.java.net)
の prototype-1.7-b05.jar 試してみれば分かるけど
property を言語全体に影響する予約語にする事無く、property でプロパティの定義させてる。

常に予約語にする必要がないってわけじゃないけど、
導入する構文によっては予約語にする必要はない。
もしくは、予約語にしないように導入する構文を慎重に決める必要がある。

792:デフォルトの名無しさん
07/03/31 17:00:14
予約語にしたほうが構文解析が楽とか紛らわしいのがなくなるとかメリットもあるから
単純にはいえんよ

793:デフォルトの名無しさん
07/03/31 17:17:48
>>789
なんか一言で失敗作呼ばわりされてしまったなぁｗ

794:デフォルトの名無しさん
07/03/31 17:40:08
>>792
「property を予約語にしない」ってのを選択肢として持ってないのは不勉強。

795:デフォルトの名無しさん
07/03/31 17:58:51
勉強厨か
上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ
gotoだって使わないが予約語だし、newだって予約語にしなくても本当は使えることは使える

796:デフォルトの名無しさん
07/03/31 18:01:38
> 上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ
既出。

797:デフォルトの名無しさん
07/03/31 20:18:57
>>796
「既出。」だけのレスは2ch不勉強

798:デフォルトの名無しさん
07/03/31 23:32:26
propertyっていう変数は、結構使われてると思うけどな。

799:デフォルトの名無しさん
07/04/01 11:57:31
>>792
紛らわしさって？

property を予約語にしない場合の紛らわしさって言っても
せいぜい property property が出来るぐらいだと思うが。

800:デフォルトの名無しさん
07/04/01 12:05:25
×property property が出来る
○class property がある時に property property property が出来る

もっとも、>>785 も >>788 も具体的な構文規則も例も書いてないから、
>>785 >>788 の脳内構文で出来るのかは知らんけど。

801:デフォルトの名無しさん
07/04/01 15:41:45
>>781
前にGenerics使うと長くなるからtypedefいるだろとか言ってたC++信者がいたが
これはほんとに可読性に問題起こしそうだな……
どうにかならんもんか

802:デフォルトの名無しさん
07/04/01 15:52:49
>>801
URLﾘﾝｸ(blogs.sun.com)

Type aliasing
Shorthand syntax for declaring local variables

803:デフォルトの名無しさん
07/04/01 16:57:04
>>802
結局は、独自定義があるとそれによって可読性が落ちるかもしれないから
適用範囲に十分注意ってとこだな

804:デフォルトの名無しさん
07/04/01 18:00:26
Ada風に別名を付けるときに元の型から値の有効範囲縛れるように出来ると良いな。

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

typedef month byte 1...12;

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

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

キャストは値の範囲が大きい方から小さい方の場合は代入されている値が小さい方で表せる範囲の場合のみ、または小さい方から大きい方。

805:デフォルトの名無しさん
07/04/01 18:12:17
>>804
それこそアノテーションでいいんじゃないか？

806:デフォルトの名無しさん
07/04/01 18:34:49
>804
飽和演算もほしくなるな

807:デフォルトの名無しさん
07/04/01 18:52:21
JavaBeansのフィールドやセッターにアノテーションってのが現実的だな
範囲外がきたとき例外出すのか、飽和させるのか、値を変えないのかの判断もいれればグッド
ついでに一番面倒なプロパティリスナのfireも自動でやってほしい

808:デフォルトの名無しさん
07/04/01 21:53:14
>>807
その情報を元にWebアプリ側で自動でバリデートやエラーメッセージ出してくれたら最高に楽だな。

809:デフォルトの名無しさん
07/04/01 22:05:41
>>808
なんかライブラリとNetBeansでプラグイン作りたくなってきた
GUIとのバインディングでもかなり効率よさそうだしな

810:デフォルトの名無しさん
07/04/01 22:41:26
プロパティなど要らぬ！
構文糖・即・悪こそが我々Java厨の共有する唯一の正義ではなかったのか！

それを捨てるというならば、まずtypedefを導入しやがれ

811:デフォルトの名無しさん
07/04/01 23:14:33
Genericsは構文糖じゃねーのかよ
生成されるバイトコードはキャスト使いまくりのものと同じだろ

812:デフォルトの名無しさん
07/04/01 23:28:04
>>810
そんなもん、EoD とか言って autoboxing みたいな構文糖が入った時点で捨てとるような。

813:デフォルトの名無しさん
07/04/02 00:10:56
>>811
乙

814:デフォルトの名無しさん
07/04/03 11:11:13
>>810
何かいまいち語呂が悪いな

というかtyprdefはねえよwww

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

copy(Cloneable obj)とかif(obj instanceof Cloneable){/*処理*/}とかそういうことは出来なくなるけど……

816:デフォルトの名無しさん
07/04/03 19:40:24
いやtypedefは欲しい。
Javaで導入されていないのは、sourceが読みにくくなるという理由だろうけど。

817:デフォルトの名無しさん
07/04/03 21:04:57
typedef String MyString;
みたいなのは同じ型の別名を作るだけだから有害だが、
typedef Map<String, List<MyClass<Integer, String>>> MyType;
みたいなのは特別な組み合わせに特別な名前をつけているから有用だと思う。

だから、Genericsありの場合のみtypedefを許すというのはどうだろうか。

818:デフォルトの名無しさん
07/04/03 21:12:11
class MyType extends Map<String, List<MyClass<Integer, String>>>{}

819:デフォルトの名無しさん
07/04/03 21:31:09
>>816
実態が変わるのならきっついのでは？
Javaはすべてダイナミックリンクなわけで
Stringからchar[]への変更とかIntegerからLongへの変更とか現実的ではないし

820:デフォルトの名無しさん
07/04/03 21:38:01
これさー

typedef　String　MyString;
MyString　abc　=　"sample";

これ、OK　にするん？　NG　にするん？

821:デフォルトの名無しさん
07/04/03 21:44:12
>>818
それでいけるかー

typedefのためだけにファイルいっこつくるのが許容できるかどうかだな

822:デフォルトの名無しさん
07/04/03 21:51:09
>>821
逆にファイル一個作らない場合、どのソースファイルに記述するか迷わないか？
ひとつのクラス内でのみ使用するというならいいが。

823:デフォルトの名無しさん
07/04/03 21:53:30
>>818
擬似Typedefアンチパターン
URLﾘﾝｸ(www-06.ibm.com)

824:デフォルトの名無しさん
07/04/03 22:27:37
extendsに関してはあまり的を得ているとはいえない批判だな。
公開APIで使うべきではないけど、内部処理で使うには問題はなかろう。
「大規模では・・・」というのも、モジュール境界で使わなければいいだろう。

825:デフォルトの名無しさん
07/04/03 22:33:36
>> 820
OKだろ。

826:デフォルトの名無しさん
07/04/03 22:59:03
>824
当を得る、的を射ると書こうと思ったが
"的を得る"もあながち間違いとはいえないらしい

827:デフォルトの名無しさん
07/04/03 23:09:14
>>820
そんなん言語仕様作ってる連中が居るところで聞かなきゃ意味がない。

どーせやるなら generics のパラメタ型だけじゃなくて
JSR 308 の型へのアノテーションも含めて欲しいけど。

828:デフォルトの名無しさん
07/04/03 23:35:42
typedef派の諸君！ Java7で何かが変わると思ったら大間違いだ！
所詮dolphinなんか、property派のお祭に過ぎない！
我々typedef派にとってdolphinほど馬鹿馬鹿しいものはない！
多数決で決めれば、property派が勝つに決まってるじゃないか！

829:デフォルトの名無しさん
07/04/04 00:16:01
俺は言語使用云々よりもMVMが最も重要だと思う。
MVMさえ実現されれば、デスクトップJavaもサーバJavaもかなりの勢いで道が開ける。

830:デフォルトの名無しさん
07/04/04 00:44:35
俺もそうは思うが、MVMって実装される予定はあるのか？

831:デフォルトの名無しさん
07/04/04 01:12:55
>>828
俺はビビらない

もうちょっと上手くやってください

>>830
俺がずっとヲチしてるとこは年単位で動きナス
URLﾘﾝｸ(research.sun.com)
URLﾘﾝｸ(java.sun.com)
唯一怪しげな情報として引っかかってきたのが
URLﾘﾝｸ(jvmcomm.stage.dev.java.net)
ここによると、MVMは作られた、とのこと。
もしかして、通常権限だとアクセスできない
URLﾘﾝｸ(mvm.dev.java.net)
に何らかの情報が？誰か触った事のある奴居ないっすか？

次ページ