[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/ 543 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 22:22:37 ] >>533 んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件 コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。 そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ 併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ マクロはないから文法ひっくりかえすような表記でコードは書けないけど、 それはC/C++でも行儀良くないからな。 544 名前：543 mailto:sage [2007/02/28(水) 22:31:04 ] スレ違いの話だけだとあれなんでSEの話もふっとく。 techon.nikkeibp.co.jp/article/HONSHI/20070220/127928/ ↑ OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って OSGi始めたのにいまさら梯子外すのはないよなあ。 545 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 09:21:12 ] >>543 >#ifdefのような条件 >コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん だからそれはJ2SEのような環境が統一されている場合の話であって、 機種依存が激しい携帯ではなりたたないって。 VMですら機能やバージョンが違うのに。 >そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ >併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。 インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。 546 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:02:45 ] >>543 >#ifdefのような条件 >コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん MEで一つのソースの中に複数ターゲット向けのコード混ぜたら絶望的なソースになるよ？ 最低プロファイル・機種毎にソース分けんと確実に死ねる。 jadも分けんとたまにハマるから油断できん！ 547 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:13:36 ] あー言い忘れたeclipseでリファクタリングしただけでエミュでは動いて実機では動かなくなるのがMEの世界だ。 システムが勝手に走らせる特定のスレッドの実行が一定時間以内に終わらないと強制終了とか。 実行時例外catchしてcatch節でコード実行すると問答無用で落とすとか（catchしても何もしなければ良かったり、ときにはcatchすら許してくれない） あと実機じゃ機嫌悪いと動くコードもマジで動かん。 MEでプリプロセッサ使ったソースなんて保守以前の問題。 548 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:58:01 ] >>545 >だからそれはJ2SEのような環境が統一されている場合の話であって、 >機種依存が激しい携帯ではなりたたないって。 >VMですら機能やバージョンが違うのに。 つーか、J2SEでも、Sun/IBM VM間のクセの違いの吸収や、 Sun VMでもSwingの1.4, 5, 6での差を吸収させるのに、#ifdefは欲しい。 549 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 11:39:58 ] いやだからそういう次元じゃないとｒｙ MEやれ 550 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 00:07:56 ] >>548 SEで、ifdefは勘弁して欲しい。 それなら、せめて其処のコードは別クラスに分けて設計してくれよ・・・ 551 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 20:50:21 ] JDK7 build09 download.java.net/jdk7/changes/jdk7-b09.html download.java.net/jdk7/binaries/ 何だろう？2回続けてサマリがないビルドだ・・・ まあ今回もupdateするけど〜 552 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 21:32:24 ] >>551 >>470 のリンク先見たら前回のは出てる。 ビルド方法でトラブってて changes が自動生成できてないから、 後から手動で生成してるとか？ それとも単に怠慢で遅れてるだけ？ 553 名前：デフォルトの名無しさん [2007/03/03(土) 07:27:48 ] フィールドのgenericTypeを取りたいんだが方法はある？ 例：List<Integer> listのInteger 554 名前：デフォルトの名無しさん [2007/03/03(土) 08:19:37 ] >>544 べつに無理にJava標準に含めることを早めなくても問題なかろ。 早めることよりもむしろ、理にかなってこそ導入すべきだが。 Javaを駄目にするおそれがあるとしてJavaに導入することをまだ認めていないだけだと思うぞ。 JCPは少なくとも、Java SE 1.3以降からの上位互換性をもの凄く気にしているようだから 下手にほいほいと導入するわけにはいかんでしょうや。 そう考えると、enum型の導入が遅くなった理由もなんとなくわかる。 OSGiはなぜかEclipse Communityががんばっているようだし。 Eclipseのプラグインフレームワークに導入されているが、 SunとIBMだもんね。そういうところでは決して仲がよいとはいえないしねえ。 SWTを巡る技術的な問題もあるし。Swingは遅いからSWTを作ったと主張してきたIBM に不信感を抱いているのではないかな？ 555 名前：デフォルトの名無しさん [2007/03/03(土) 08:22:53 ] >>548 駄目だお前。 ソフトウェア工学をなめとる。 修行が足りんぞ。 556 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:24:07 ] >>553 get(i) 557 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:28:45 ] >>553 download.java.net/jdk/jdk-api-localizations/jdk-api-ja/builds/latest/html/ja/api/java/lang/reflect/ParameterizedType.html 558 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:50:51 ] >>557 $ cat Test.java import java.util.List; import java.util.ArrayList; import java.lang.reflect.ParameterizedType; import java.lang.reflect.Type; public class Test { public static void main(String[] args) { ArrayList<Integer> l = new ArrayList<Integer>(); Type type = l.getClass().getGenericSuperclass(); ParameterizedType pt = (ParameterizedType)type; for (Type t: pt.getActualTypeArguments()) { System.out.println(t); } } } $ java Test E ありゃ。 559 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 09:02:20 ] class IntegerList extends ArrayList<Integer> {} public class Test { public static void main(String[] args) { Type type = IntegerList.class.getGenericSuperclass(); for (Type t: ((ParameterizedType)type).getActualTypeArguments()) { System.out.println(t); } } } とすると class java.lang.Integer となるな。 560 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:03:18 ] >>553 List<Integer> の Integer はコンパイル時に情報消えるよ。 >>559 みたいなのは特殊な例。 561 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:15:54 ] って、ローカル変数じゃなくてフィールドの宣言についてか。 public class test {     public List<Integer> sample;     public static void main(String[] args) throws Exception {         for (Type t: ((ParameterizedType)test.class.getField("sample").getGenericType()).getActualTypeArguments()) {             System.out.println(t);         }     } } >java test class java.lang.Integer 562 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:21:52 ] >>558はgetClassしてる時点でどうなるかをかんがえればよろし 563 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 14:24:41 ] >>553 初心者質問スレ行けよ。 564 名前：デフォルトの名無しさん [2007/03/03(土) 15:28:47 ] >>556-563 �d 565 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 09:29:05 ] >>551 追記： 見た目で大きく変わるところ発見。 Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！ 可愛いです。 デュークのライセンス変更で、こういう事になったのね わかりにくいカップよりコレはいいな 566 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 16:02:11 ] invokedynamic 使えるかどうかプログラム側から判断するのって、どうすれば良いですか？ 567 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 16:44:34 ] >>566 実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、 エラー出たら使えないんじゃね？ そーいや、invokedynamic って今どーなってんだろ？ invokedynamic のオペランドとかの詳細あったっけか？ 568 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 15:34:36 ] 某スレの 288 へレス。 > クロージャよりは揉めずに入りそうな気がしてる。 ウソはいかん。javac の人なんかはイラネって言ってるし。 blogs.sun.com/ahe/entry/java_se_7_wish_list 要は、プロパティに dot でアクセスしようとすると、 既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。 例えばフィールド宣言したコンパイル単位ではフィールドアクセスで それ以外ではプロパティアクセスとか、 プロパティと同名のフィールド持てないとか、そんな感じのルール。 どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。 もしくは "->" とかでプロパティにアクセスする とかだけど、これはこれでキモイから嫌なんだそうで。 weblogs.java.net/blog/forax/archive/2007/01/property_reload.html ksl でプロパティの試験実装してた人とかも、 Access to property は setter getter で、って意見変えてるし。 569 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:20:57 ] >>568 そうか、キモイか・・・うん、キモイなぁ dotを使うのは、駄目と言う点は全く賛成だが 表記方法さえ、決まればOKだと思ってるんだけどなぁ 俺は、個人的な好みは->はキモイけど、 : ならOKです。 570 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:41:54 ] :: . .* -> ->* いろんな言語のaccessor。あと何があったっけ？ 571 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:48:11 ] >>569 オレ自身は "->" でもいいじゃん、とか思ってたりする。 他の人が "->" がキモイって言うのも理解できるんだけど。 jroller.com/page/scolebourne?entry=property_access_is_it_an ${classInstance.propertyName} みたいに ${} で括った部分では 式言語使えるようにすりゃええやん、ってのも出てるけど…… そこまでして dot に拘らんでも、と思わなくもない。 572 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:14:36 ] >>569 :: じゃなくて : なの？ class A { property Object b; } class B { property Object c; } class Hoge { 　A a; B b; Object c; 　boolean flag; 　Object method(){ 　　return flag ? a : b : c; 　} } とかされると分かりにくくなるよーな気もする。 構文解析自体は結合順位とかがあるから出来ると思うけど。 573 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:15:17 ] dot人気ないね。 フィールドアクセスとプロパティのインターフェースを別のものにしたら、 単なるgetter/setterの省略表記になってしまってあまりうまみがないと 思うのは俺だけかな？ 574 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:42:44 ] >>573 皆が納得できる上手いルールが作れれば dot でも良いと思うけど。 人気がないって言うよりも、>>568 のような追加ルールを決める部分を 誰もやりたがらないような気もする。 簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、 なるべく互換性維持しようとすると、ルールが複雑になって 今度はコンパイラの作者とかから嫌われるだろうし。 >>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、 もしくは問題自体を理解してないような。 C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、 Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから getter/setter の省略表記と割り切った方が現実的じゃないかな？ 575 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 22:38:47 ] >>572 あ、いや、: ←コロンを使うという意味だった。 Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。 一つだと、 hogehoge==null？a : b; とか、switchが混乱するから。 >>573 いや、むしろそれがいい。 見たら裏で何をしているかがよく分かる。 別に、dotではなくて :: でも可読性は落ちないと思う。 -> は、演算記号と紛らわしくて、嫌。 576 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:03:00 ] プロパティなんてそもそも本質的には冗長な機能なんだから、 どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。 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 だよな。 いらないと思うよな。

---

---

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

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