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

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/ 577 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:08:52 ] > マイクロソフト系の言語と同じ記法でいいと思うんだがなあ。 具体的には？ 578 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 03:22:06 ] C++で->使ってるから、->でいいや。 579 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 04:10:14 ] >>576 VBだとdotじゃなかったっけ？ 580 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:32:28 ] >>577,579 VB,C#ともどっとだね。 仕様策定してる連中がドットを嫌う理由がよくわかんない。 どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから 新しくプロパティの意味を持たせても別にいいと思うんだが。 581 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:50:48 ] >>580 C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？ まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。 Javaに、そんなルール後付けしたら互換性無くなるし。 なんでこんな簡単な事が理解できないのかわかんない。 582 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:55:00 ] >>581 プロパティ自体後付けじゃん…て思ったんだけど、 setter/getterペアにアクセスする演算子のことなのか。 プロパティ定義の構文も新しく作るのかと思ったよ。 C#の Property Hoge { 〜 } みたいにさ。 だったら「そんなもんｲﾗﾈ」に一票だなあ 583 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 09:19:05 ] >>582 > プロパティ自体後付けじゃん…て思ったんだけど、 JavaBeans のプロパティ自体はあって、その構文糖を追加しなければならない。 だから、完全に後付けってわけでもない。 JavaBeansのプロパティや、それを使ってる既存のフレームワーク捨てるなら別だけど。 あとプロパティ定義の構文を新しく作っても、プロパティアクセスに dot 使えば問題は出る。 例えば、 class MyComponent implements java.beans.DesignMode { 　private boolean designTime; 　public boolean isDesignTime(){ return designTime; } 　public void setDesignTime(boolean f){ designTime = f; } } みたいな既存のコードがあるとする。 プロパティが追加されて java.beans.DesignMode が interface DesignMode { 　public static final String PROPERTYNAME = "designTime"; 　public abstract property designTime; } みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。 584 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 09:57:09 ] >>580 > 仕様策定してる連中がドットを嫌う理由がよくわかんない。 dot 使ったらフィールドアクセスとプロパティアクセスの区別がつかなくなると何度言えば…… 585 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 10:02:47 ] >>580 > どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから ひょっとして、現存するソースコードに Beans のプロパティ持ってるものが 大量にあるって事がわかってない？ 586 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:37:56 ] だからさ、プロパティってのはgetter/setterペアのことじゃなくて それとは別に新しい概念を持ち込むのかと思ってたって>>582に書いたでしょう。 何嬉しそうにツッコミいれてんだよ。 587 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:41:08 ] > 何嬉しそうにツッコミいれてんだよ。 いや、無知だなぁ、と思って。 588 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:51:08 ] >>587 どの辺が無知だったか教えてちょ。勉強するから。 589 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:56:57 ] >>588 このスレに出てるのだけでも、プロパティに関するリンク先読んでれば beans と関係のない新しいプロパティを導入するとか思わんでしょ。普通。 590 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 13:21:21 ] >>589 そうだな。すまんかった。 591 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:35:44 ] >>583 >みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。 ここがよくわかんないんだけど、誰か解説して。 アクセッサがあればそちらを優先的に使う（あるいは逆にフィールドアクセスを優先する）というルールを決めればすむ話じゃないの？ で、583みたいな状況になったらコンパイラが警告を出してくれればそれでいいと思うんだけど。 592 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:47:38 ] >>591 > アクセッサがあればそちらを優先的に使う それやったらコンパイルが通らん。 > フィールドアクセスを優先する フィールドでプロパティを上書きできるようになるけど、それで良いんか？ 593 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:56:24 ] × フィールドでプロパティを上書き ○ フィールドでプロパティを覆い隠し 594 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:00:25 ] >>592 > > アクセッサがあればそちらを優先的に使う > それやったらコンパイルが通らん。 いや、コンパイルは通るかもしれんが…… 例えば > public boolean isDesignTime(){ return designTime; } は public boolean isDesignTime(){ return isDesignTime(); } に展開されるから実行時に StackOverflowError 吐いて死ぬ。 595 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:20:38 ] >>584 区別させないのがプロパティだろうに。 596 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:24:32 ] >>595 コンパイラが区別できないって意味なんだけど。 人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。 597 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 22:11:17 ] >>596 まぁ互換性を維持してのプロパティの導入には実装上の困難を 解決できていないというのはいいんだが、だからといって 「できる方法で実装しちゃおう」となるとしたら賛成できないなぁ。 互換性の面から考えた場合、方法は大きく3種類に分類できて、 1.JavaBeansと相互に互換性のある方法 2.JavaBeansとは互換性がないが、バイトコードレベルでの 　仕様変更を伴わない方法 3.バイトコードレベルで拡張する方法 このうち、3.を採用すると何でもありだから議論から除外するとして、 個人的には1.には拘らないから2.でうまいことやってくれないかなと 思うんだが。 598 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:05:53 ] >>597 1 の場合はともかく、2 や 3 の場合は コンパイラ実装するとか言語仕様追加する、 とかってのは一番楽な部分だからね。 JavaBeans を切り捨てるってのは、技術的というより政治的な問題だから、 ハッカー気質が強い人ほど、自分でコード書いたりする時間がなくなって 政治的な問題に時間を取られる、って予感があるので手を引きたがる。 2 の場合は機能を欲しがる人は居るかもしれんけど、 （2 をやれるだけの政治的立場とか確保してる人の中で） やりたがる人は居ないと俺は思うから、たぶん実現できないと思う。 599 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:18:49 ] > JavaBeans を切り捨てるってのは 切り捨てるわけじゃないか…… でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか 標準API とかの setter/getter を新プロパティで置き換えるとかってなれば 厄介な政治的問題だってのは予想できるでしょ。 言語として 2 のプロパティ持ってても、 標準API は 2 のプロパティをサポートしませんとかなったら間抜けだし。 600 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:26:45 ] > でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか こんな決定したら 袋叩きにあうような気もする。 メンテ面倒くさいし。 enum でも、似たような事やってたけどさ。 enum だと、自前の enum を定義するクラスが比較的少ないから メンテが面倒って不満がそれほど大きくならんかっただけだと思うし。 601 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:30:42 ] XMLEncoderがenumに対応してないと気づいたときに、Javaは終わったと思った。 602 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:34:54 ] これ? bugs.sun.com/bugdatabase/view_bug.do?bug_id=5015403 603 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 08:40:52 ] >>592 >それやったらコンパイルが通らん。 だから具体的に説明してくれって。頭の悪い俺でも分かるように。 >フィールドでプロパティを上書きできるようになるけど、それで良いんか？ これが問題になるのって、フィールドがnon privateのときだけだよね。 フィールドもアクセッサもpublicというのはちょっと考えにくいから、これでも別にいいと思うけど。 >>594 >例えば >> public boolean isDesignTime(){ return designTime; } >は public boolean isDesignTime(){ return isDesignTime(); } >に展開されるから実行時に StackOverflowError 吐いて死ぬ。 これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 これなら大丈夫じゃない？ 604 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:35:33 ] >>603 > これが問題になるのって、フィールドがnon privateのときだけだよね。 違う。例えば class A{ public int field = 0; } class B extends A{ private int field = 1; } class C { public static void main(String[] args){ 　System.out.println( new B().field ); } } とかだと A の field にアクセスできんでしょ？ つまり、private なフィールドでも public なプロパティを覆い隠せる。 ってか、言語仕様読んでも、なんで Ａ の field にアクセスできないのか 俺には良くわからんのだが…… 覆い隠しって単純名だけに作用するんじゃないんかな？ > これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。 そうだよ。だから無理だって言ってるじゃん。 > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。 605 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:38:13 ] >>603 > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 > これなら大丈夫じゃない？ package-private もしくは protected な フィールドと、 public なプロパティで問題起こるから解決になってない。 606 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 10:13:00 ] >>604 > 覆い隠しって単純名だけに作用するんじゃないんかな？ 違うか。覆い隠しじゃなくて、隠蔽されたフィールドは継承されないから、 B のインスタンスからは A の field にはアクセスできないのか。 名前の章ばっかし見てたら理解できんかった。 607 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 10:17:35 ] どっちにしろ、今更プロパティを言語仕様に導入しようなんて考えるのが間違ってる。 608 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 12:25:26 ] 間違い、とまでは思わないけどね。 609 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 13:47:17 ] >>603 > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 これだと、他にも穴があるか。 class A implements Compareble<A>{ 　private int field; public long getField(){ return field; } 　public int compareTo(A another){ return this.field - another.field; } } とかがコンパイルエラーになる、と。 610 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 15:00:26 ] > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 (this).bar とかだと どうすんだろ？ 611 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 16:53:37 ] ってか、そーゆールールなら ・フィールドが可視ならフィールドアクセス ・そうでなければ、プロパティがあるならプロパティアクセス とかの方が良いような気もする。 それでも static なプロパティを許したりすると、同名のメンバークラスと衝突するし。 ってか、同名のフィールドが可視なら shorthand syntax for accessing properties を使えないのって、本当に使いやすいかも結構問題のような？ 612 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:42:20 ] 何か激しく壊れてない？ ttp://download.java.net/jdk7/binaries/ 613 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:42:27 ] >>604 >違う というのは勘違いということでいいのかな？ >そうだよ。だから無理だって言ってるじゃん。 だから『 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく』といっているんだけど。 >そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。 なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。 614 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:48:30 ] >>613 ＞なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。 汚い設計。 わかりにくいです。 あとマルチスレッド周りで問題がでそうだな。 615 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:05:41 ] >>613 > というのは勘違いということでいいのかな？ いや、覆い隠しは勘違いだったけど、 private フィールドで public なプロパティを隠蔽できるから問題になるのは変わらない。 > 区別してないなら区別すればいいじゃん。 区別しても、 >>605、>>609、>>610 みたいな穴があるから、やるだけ無駄。 616 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:44:57 ] >>611 どっちかっつーと dot でプロパティアクセス許す場合、 フィールドと同名のプロパティを作れるってのが混乱の元だとか認識されてんのかも？ 617 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:51:03 ] > あとマルチスレッド周りで問題がでそうだな。 問題でるかな？ 618 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:53:23 ] >>613 > なんで無茶なの？ 根本に近い方のルールを書き直すってのは、 既存のコンパイラを改変する時に多くの労力がかかりそうだってのは分かるでしょ？ だから無茶なの。 619 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 21:20:36 ] >>571 > ${classInstance.propertyName} みたいに ${} で括った部分では > 式言語使えるようにすりゃええやん、ってのも出てるけど…… ksl の 課題追跡にあった https://ksl.dev.java.net/issues/show_bug.cgi?id=2 に似てるっちゃ似てるかも。 でも、ecmascript みたいに Java と同じく } でブロック終了する言語だと 対応とるの大変そうだなとか思った。その辺は EL だと楽だけど。 620 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 21:34:43 ] ヒアドキュメント＋式言語ってのが良さそう Velocityが標準になるみたいな感じだが。 621 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:29:53 ] >>616 要は、今の仕様で private int xxx; というフィールドと public int getXxx() というメソッドが混在できる以上、フィールドの延長上のプロパティと getter/setterの延長上のプロパティとは相容れないわけだ。 いまのキモいJavaBeansのgetter/setterはプロパティとはなんの 関係もないことにすりゃ、それで解決すると思うんだけどね。 622 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:49:49 ] >>621 > いまのキモいJavaBeansのgetter/setterはプロパティとはなんの > 関係もないことにすりゃ、それで解決すると思うんだけどね。 仮に、それをやっても「解決する」のは言語仕様の問題だけで、 ライブラリ＆フレームワーク＆ユーザーコードの方に問題を押し付けてるのような。 それなら、ぶっちゃけ新しい言語作っちゃった方が速いと思う。 623 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:18:12 ] >>622 上の方でだれか言ってたけど、フレームワークのプロパティとは無関係な「Java言語プロパティ」 を作ってもいいんじゃないか。紛らわしいなら名前は変えてもいいけど。 そもそもなんでプロパティ構文が欲しいんだ。ドットネットが羨ましいんだろうか。 624 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:24:53 ] >>622 「問題」って、どんな問題かな？ 別に既存コードの変更が迫られるわけじゃないっしょ？ 625 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 00:09:08 ] >>623 むしろstructが羨ましいんじゃないか？ 626 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 02:48:40 ] >>624 互換性を確保しつつ新プロパティを使おうと思ったら、 既存のプロパティと、新プロパティの両方管理しなきゃいけなくなる。 二重のコストを払う必要が出るんだから、普通は問題になる。 おまけに、フレームワークやライブラリが二重のコストに耐えかねて 既存のプロパティを捨てたら、やっぱり既存のコードを書き換える必要が出る。 直接コードの変更を迫ってないだけで、間接的にコードの変更を迫ってる。 627 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 07:18:35 ] >>626 プロパティが導入されたからといって、既存のコードを無理に 対応させることはないでしょ？別物なんだから。 それに例えば、ジェネリクスが導入されたとき、それに対応して 書き換えられたフレームワークはあったし、もちろんそれを利用 しているユーザーコードも書き換えられることがあったけど、 それは別に変更を余儀なくされて行ったわけじゃないよね？ 628 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 07:52:01 ] >>627 > それに例えば、ジェネリクスが導入されたとき、それに対応して Generics の場合は「JavaBeans とは無関係なプロパティ」導入と違って、 例えば Collection フレームワークを Generics対応に書き換えたら、 互換性が完全に無くなるってわけではなかったけど、 「JavaBeans とは無関係なプロパティ」の場合は、 「JavaBeansのプロパティ」のサポートをうちきれば互換性が無くなるし。 例えるなら enum の方が近いな。int enum と typesafe enum の両方を提供してるAPIがあって。 それにはコストがかかる。int enum だけ、typesafe enum だけを提供してるAPIもあるけど、 プロパティの場合は影響範囲も、統一的に扱う必要性も enum の時より大きいから 両方の提供がより大規模に起こるのは容易に想像できる。 「JavaBeansのプロパティ」と「JavaBeans とは無関係なプロパティ」は共存可能って話なんだろう？ 互換性維持のためには「JavaBeansのプロパティ」が必要で、 新機能対応のためには「JavaBeans とは無関係なプロパティ」が必要で、 それを両方管理しようとすりゃコストはかかる。問題になるだろ、普通は。 629 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:10:26 ] 定義はgetter/setterで行って、呼び出すときだけプロパティみたいにも使えるようにするのじゃダメ？ 例えば、p=a.getXxx()をp=a.xxx、a.setXxx(p)を a.xxx=pとか。 630 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:37:50 ] >>629 それだと dot でやるのが面倒。 既存の getter/setter に使われてる「プロパティの名前」と 同名のフィールドが存在可能だから。 631 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:39:25 ] >>628 そのコストってのもフレームワークの作者とかはともかく開発者は関係ないね 632 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:44:16 ] >>631 何より、無駄にバグのリスクが増えるし、 標準APIとかでドキュメントの翻訳に時間がかかるようになるとも考えられるね。 633 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:45:07 ] >>631 開発者というより、末端ユーザだな 634 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 09:10:34 ] >>629 a.xxx と同名のフィールド a.xxx があった場合、扱いが面倒。 互換性を考えるなら >>611 あたりのルールが落としどころかとも思うけど、 public な同名のフィールド使えば、プロパティに触れなくする事ができたりするし、 完璧とはいいがたい。 言語仕様に書く文言も相当慎重に選ばないと、 デフォルトパッケージのクラスが import 出来なくなったみたいに、 言語仕様の文言から副作用がでる可能性も…… もっとも、import の方は意図しない副作用なのか意図的なものか、 ちゃんと知らんのだけど。 635 名前：デフォルトの名無しさん [2007/03/14(水) 12:24:27 ] マルチコア対応は言語に乗っかるのか、VMに乗っかるのか・・・ 636 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:37:32 ] >>627 Genericsは、既存の一般コードに関しては意味の変更なく使えたぞ >>632 さすがにそのコストを考えるのは臆病すぎｗｗｗ >>635 マルチコア対応って一体何なのか分からない。 なぁ、何でみんなdotにこだわるの？ 別の記号にして、定義も全く別にすればスッキリ導入なんだけど？ バイトコードは拡張しないと駄目だろうけど。 637 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:48:08 ] >>636 > 別の記号にして、 dot 以外の記号はキモイから嫌らしい。 > 定義も全く別にすれば 既存の資産と協調して使えないので、導入しても嬉しさ半減。 > バイトコードは拡張しないと駄目だろうけど。 バイトコード拡張は必要ないでしょ。 クラスファイル仕様は弄るかもしらんけど。 638 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:50:02 ] >>635 マルチCPU対応のVMだったら、マルチコアも そのまま使えるんじゃない？ ってか、マルチコア対応を言語にのっけるってどーやるんだ…… 639 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:13:07 ] そういやRhinoのLiveConnectは実装側で拡張されててJavaObjectのゲッタ(getXxx)・セッタ(setXxx)にJavaScriptObjectのプロパティ(xxx)からアクセス出来たな。 JavaBeans使ってたんだろうか？ 結局JavaScriptObjectのプロパティからアクセスしようとした時JavaObject側にxxxってフィールドがあると衝突して使い物にならないから LiveConnectには元々ない後付けされた機能なんて不完全だって言われてたな・・・。 オライリーのサイ本にも指摘されてたような。 640 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:39:56 ] >>626 阿呆だな。もっと簡単な問題があるよ。 >>624 JavaBenas のプロパティと別のプロパティなわけでしょ？ 標準API とかの既存の interface に abstract な property を追加したら 既存のコードの中で、そのinterface を実装してて JavaBeans とは別のプロパティを 実装してないクラスがあれば、互換性に問題が出る。 互換性に配慮したら interface に迂闊にプロパティ追加できない。 それだと、たぶん使い物にならない。 641 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:48:02 ] >>627 具体的に言えば java.beans.DesignMode にプロパティ追加して interface DesignMode { 　public static final String PROPERTYNAME = "designTime"; 　boolean isDesignTime(); void setDesignTime(boolean f); 　public abstract property designTime; } とかすると、既存の class MyComponent implements java.beans.DesignMode { 　private boolean designTime; 　public boolean isDesignTime(){ return designTime; } 　public void setDesignTime(boolean f){ designTime = f; } } みたいなコードを書き直す必要がある。 DesignTime とかだけならともかく、他の interface も property の追加に関しては慎重にならざるをえない。 よって interface で property にアクセスできない事が多くなる。 JavaBeans のプロパティと別の新プロパティを導入しても、 あんまし使い勝手がよくないだろうね。 642 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 14:10:45 ] なるほどいろいろ問題があるな。 結局 ->案が一番妥当だろう。 プロパティを定義する側はこれまでどおりgetXXX/setXXXを使用する。 プロパティを使用する側はgetXXX/setXXXと->XXXの両方が使える。 フィールドにXXXがあっても問題なし。 しかし、この程度のものならいらないな。 643 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:29:22 ] >>642 だよな。 いらないと思うよな。 644 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:41:27 ] あとはgetとsetを対にした定義文もほしいな 645 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:47:49 ] >>641 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入するのだったらその書き換えはいらないよね？ 646 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:03:21 ] >>645 だから、>>641 は > 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入 した場合に発生する問題だってば。 今Beansで「プロパティ」と呼んでいるもの、 要するに setter/getter呼び出す syntax sugar として accessing properties な構文を入れるなら、>>641 の問題は発生しない。 647 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:36:28 ] >>646 なんで書き換えようとするの？そのままにしとけばいいじゃん。 648 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:56:32 ] >>647 >>641 をちゃんと読め。 649 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 17:45:12 ] >>648 ちゃんと読んでもわからないです。 何故 interface DesignMode に property designTime を追加してるの？ ひょっとして俺ｽｹﾞｰアホなこと訊いてる？ 650 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 18:38:36 ] > ひょっとして俺ｽｹﾞｰアホなこと訊いてる？ うん。 651 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:27:50 ] >>641 あきれる。 isXXX()/getXXX()をgetterのインターフェースに用いたままプロパティを 実現しようとすることに問題があるから別のインターフェースを採用 しようという話なんだから、その例でinterfaceの方にisDesignTime()を 追加するという仮定自体がそもそもありえないし、仮に追加しても 何の影響もない。 652 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:35:24 ] dot以外の記号がキモイならdot二つのx..hogeでもいいよ。 653 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 23:25:14 ] >>652 孔明あらわる 654 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 23:56:34 ] >>651 俺もそんな気がしたんだけど、>>650 だそうです。 655 名前：デフォルトの名無しさん [2007/03/14(水) 23:57:20 ] 記号でわざわざ入力二回って耐えられなくない？ 656 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:00:24 ] 耐えられないなら++も--も使わずにプログラムを書いてくれ。 657 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:45:46 ] // << >> == && || ↑これらも つか==なしとか縛りきつくね？ 658 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:47:52 ] VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。 FlashのActionScript(ECMAScript派生)もread onlyプロパティがあったが、dotだね。 dot以外を選択するのは、正直コンパイラ屋の都合でしかないと感じる。 メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。 659 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 01:30:43 ] ちょっと待てECMAScriptは全部プロパティだ 660 名前：デフォルトの名無しさん [2007/03/15(木) 01:32:16 ] >>656-657 2chらしい模範解答だなｗ 661 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 01:52:21 ] IDEやJava用エディタならテンプレート機能が充実しているし そんな構文糖は要らないってのも意見として尊重してほすぃ。 662 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 02:15:35 ] >>661 どうなんだろ、セマンティクスがハッキリするから getter,setterが分かりやすくなるという点ではIDEも歓迎なのでは？ 実現方法はともかく。 663 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 04:06:26 ] >>661 コードの読みやすさが上がるのであれば、新しい構文糖の導入も大いに結構じゃないかい？ 664 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:43:28 ] >>651 あきれる。 > 仮に追加しても何の影響もない。 そんなは事ない。 665 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:47:20 ] >>651 >仮に追加しても何の影響もない。 追加したら、java.beans.DesignTime を実装している既存のクラスを書き換えなきゃいけなくなるだろう。 影響がないって、馬鹿じゃないのか？ 666 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:48:08 ] >>665 × java.beans.DesignTime ○ java.beans.DesignMode 667 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 08:18:45 ] >>661 java.net/pub/pq/142 とか見ると、 property構文は、XML構文に次いで人気がないんだよね。 java.net/pub/pq/141 とかだと、 very important と、somewhat important をあわせても 1/4 ぐらいだったりする。 まぁ、この手の投票がちゃんと機能してるかはわからんし、 構文糖なら要らないってのと、重要度が低いってのは同じ意見じゃないんだけど。 668 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 08:34:05 ] >>658 > VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。 もし問題がないなら dot を使うのに反対の人はあんまし居ないと思うんだが。 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて わかりにくくないって言うんならともかく。 > メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。 それって、何か改善する？ 669 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 09:09:07 ] >>668 > 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて > わかりにくくないって言うんならともかく。 それなら、同名のフィールドとプロパティが共存できて、 さらにフィールドもプロパティも dot でアクセスする言語がわかりにくくないって言わないと。 （dotじゃなくても良いけど同じ記号でアクセスする言語） 670 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 09:17:17 ] >>651 > その例でinterfaceの方にisDesignTime()を > 追加するという仮定自体がそもそもありえないし ……。 isDesignTime() は元からあるメソッドですが。 671 名前：649 mailto:sage [2007/03/15(木) 10:23:39 ] >>670 おまえ逃げてないで俺の質問に答えろよ。 672 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:26:26 ] >>671 質問になってない。 673 名前：649 mailto:sage [2007/03/15(木) 10:31:39 ] >>672 答えになってない。 674 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:36:21 ] >>621 それだけじゃ解決しないね。 新プロパティ(dotでアクセス)と同名のフィールドが作れるなら setter/getterのプロパティと同じ問題が起こるし、 C#みたく新プロパティと同名のフィールドが作れなくするなら、 標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。 これ以降は >>640 >>641 と同じ路線だな。 上記の書き換えを最小限に抑えようとすれば、 標準APIは極力 新プロパティを追加しない方向になるだろうから、 新プロパティの構文は言語仕様に定義されたが、 標準APIで 新プロパティが使えない、という本末転倒な事態が予測される。 つまり、使い勝手が悪い。 675 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:39:07 ] >標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。 標準APIが新プロパティを追加したら、 そのclass/interfaceを継承/実装して同名のフィールドを使っていたユーザコードの書き換えが必要になる。 676 名前：649 mailto:sage [2007/03/15(木) 10:42:44 ] やっとわかったよ。お互い説明が下手だと苦労するなｗ 677 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 11:02:59 ] >>675 まぁ、interface に「新プロパティ」を追加したら、 どっちみち そのinterface を実装しているクラスの書き換えが必要になる。 既存のコードは setter/getter は実装してても、 「新プロパティ」まで実装してて書き換えの必要がないってのは考えにくいから。 この書き換えを最小限に抑えようとすれば、 標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから 以下、>>674 と同文、と。

---

---

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

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