[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/11/20(月) 10:38:16[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向 ２
http://pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/
2006年12月にMustang Java SE 6がリリース予定
Mustangの掲げる主な目標は以下の点にある。
* 互換性と安定性および品質の向上
* Easy of Developmentの実現
* WebサービスおよびXMLサポート機能の拡張
* リソース管理や診断機能の強化
* デスクトップ環境の強化
Java SE 6 じゃじゃ馬ならし
http://www.javainthebox.net/laboratory/JavaSE6/
0552デフォルトの名無しさん
2007/03/02(金) 21:32:24>>470 のリンク先見たら前回のは出てる。
ビルド方法でトラブってて changes が自動生成できてないから、
後から手動で生成してるとか？ それとも単に怠慢で遅れてるだけ？
0553デフォルトの名無しさん
2007/03/03(土) 07:27:48例：List<Integer> listのInteger
0554デフォルトの名無しさん
2007/03/03(土) 08:19:37べつに無理にJava標準に含めることを早めなくても問題なかろ。
早めることよりもむしろ、理にかなってこそ導入すべきだが。
Javaを駄目にするおそれがあるとしてJavaに導入することをまだ認めていないだけだと思うぞ。
JCPは少なくとも、Java SE 1.3以降からの上位互換性をもの凄く気にしているようだから
下手にほいほいと導入するわけにはいかんでしょうや。
そう考えると、enum型の導入が遅くなった理由もなんとなくわかる。
OSGiはなぜかEclipse Communityががんばっているようだし。
Eclipseのプラグインフレームワークに導入されているが、
SunとIBMだもんね。そういうところでは決して仲がよいとはいえないしねえ。
SWTを巡る技術的な問題もあるし。Swingは遅いからSWTを作ったと主張してきたIBM
に不信感を抱いているのではないかな？
0555デフォルトの名無しさん
2007/03/03(土) 08:22:53駄目だお前。
ソフトウェア工学をなめとる。
修行が足りんぞ。
0556デフォルトの名無しさん
2007/03/03(土) 08:24:07get(i)
0557デフォルトの名無しさん
2007/03/03(土) 08:28:45http://download.java.net/jdk/jdk-api-localizations/jdk-api-ja/builds/latest/html/ja/api/java/lang/reflect/ParameterizedType.html
0558デフォルトの名無しさん
2007/03/03(土) 08:50:51$ 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
ありゃ。
0559デフォルトの名無しさん
2007/03/03(土) 09:02:20public 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
となるな。
0560デフォルトの名無しさん
2007/03/03(土) 11:03:18List<Integer> の Integer はコンパイル時に情報消えるよ。
>>559 みたいなのは特殊な例。
0561デフォルトの名無しさん
2007/03/03(土) 11:15:54public 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
0562デフォルトの名無しさん
2007/03/03(土) 11:21:520563デフォルトの名無しさん
2007/03/03(土) 14:24:41初心者質問スレ行けよ。
0564デフォルトの名無しさん
2007/03/03(土) 15:28:47㌧
0565デフォルトの名無しさん
2007/03/04(日) 09:29:05追記：
見た目で大きく変わるところ発見。
Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！
可愛いです。
デュークのライセンス変更で、こういう事になったのね
わかりにくいカップよりコレはいいな
0566デフォルトの名無しさん
2007/03/05(月) 16:02:110567デフォルトの名無しさん
2007/03/05(月) 16:44:34実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、
エラー出たら使えないんじゃね？
そーいや、invokedynamic って今どーなってんだろ？
invokedynamic のオペランドとかの詳細あったっけか？
0568デフォルトの名無しさん
2007/03/11(日) 15:34:36> クロージャよりは揉めずに入りそうな気がしてる。
ウソはいかん。javac の人なんかはイラネって言ってるし。
http://blogs.sun.com/ahe/entry/java_se_7_wish_list
要は、プロパティに dot でアクセスしようとすると、
既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。
例えばフィールド宣言したコンパイル単位ではフィールドアクセスで それ以外ではプロパティアクセスとか、
プロパティと同名のフィールド持てないとか、そんな感じのルール。
どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。
もしくは "->" とかでプロパティにアクセスする とかだけど、これはこれでキモイから嫌なんだそうで。
http://weblogs.java.net/blog/forax/archive/2007/01/property_reload.html
ksl でプロパティの試験実装してた人とかも、
Access to property は setter getter で、って意見変えてるし。
0569デフォルトの名無しさん
2007/03/11(日) 17:20:57そうか、キモイか・・・うん、キモイなぁ
dotを使うのは、駄目と言う点は全く賛成だが
表記方法さえ、決まればOKだと思ってるんだけどなぁ
俺は、個人的な好みは->はキモイけど、 : ならOKです。
0570デフォルトの名無しさん
2007/03/11(日) 17:41:54.
.*
->
->*
いろんな言語のaccessor。あと何があったっけ？
0571デフォルトの名無しさん
2007/03/11(日) 17:48:11オレ自身は "->" でもいいじゃん、とか思ってたりする。
他の人が "->" がキモイって言うのも理解できるんだけど。
http://jroller.com/page/scolebourne?entry=property_access_is_it_an
${classInstance.propertyName} みたいに ${} で括った部分では
式言語使えるようにすりゃええやん、ってのも出てるけど……
そこまでして dot に拘らんでも、と思わなくもない。
0572デフォルトの名無しさん
2007/03/11(日) 18:14:36:: じゃなくて : なの？
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;
}
}
とかされると分かりにくくなるよーな気もする。
構文解析自体は結合順位とかがあるから出来ると思うけど。
0573デフォルトの名無しさん
2007/03/11(日) 18:15:17フィールドアクセスとプロパティのインターフェースを別のものにしたら、
単なるgetter/setterの省略表記になってしまってあまりうまみがないと
思うのは俺だけかな？
0574デフォルトの名無しさん
2007/03/11(日) 18:42:44皆が納得できる上手いルールが作れれば dot でも良いと思うけど。
人気がないって言うよりも、>>568 のような追加ルールを決める部分を
誰もやりたがらないような気もする。
簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、
なるべく互換性維持しようとすると、ルールが複雑になって
今度はコンパイラの作者とかから嫌われるだろうし。
>>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の
blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、
もしくは問題自体を理解してないような。
C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、
Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから
getter/setter の省略表記と割り切った方が現実的じゃないかな？
0575デフォルトの名無しさん
2007/03/11(日) 22:38:47あ、いや、: ←コロンを使うという意味だった。
Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。
一つだと、 hogehoge==null？a : b;
とか、switchが混乱するから。
>>573
いや、むしろそれがいい。
見たら裏で何をしているかがよく分かる。
別に、dotではなくて :: でも可読性は落ちないと思う。
-> は、演算記号と紛らわしくて、嫌。
0576デフォルトの名無しさん
2007/03/11(日) 23:03:00どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
0577デフォルトの名無しさん
2007/03/11(日) 23:08:52具体的には？
0578デフォルトの名無しさん
2007/03/12(月) 03:22:060579デフォルトの名無しさん
2007/03/12(月) 04:10:14VBだとdotじゃなかったっけ？
0580デフォルトの名無しさん
2007/03/12(月) 08:32:28VB,C#ともどっとだね。
仕様策定してる連中がドットを嫌う理由がよくわかんない。
どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
新しくプロパティの意味を持たせても別にいいと思うんだが。
0581デフォルトの名無しさん
2007/03/12(月) 08:50:48C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？
まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。
Javaに、そんなルール後付けしたら互換性無くなるし。
なんでこんな簡単な事が理解できないのかわかんない。
0582デフォルトの名無しさん
2007/03/12(月) 08:55:00プロパティ自体後付けじゃん…て思ったんだけど、
setter/getterペアにアクセスする演算子のことなのか。
プロパティ定義の構文も新しく作るのかと思ったよ。
C#の Property Hoge { ～ } みたいにさ。
だったら「そんなもんｲﾗﾈ」に一票だなあ
0583デフォルトの名無しさん
2007/03/12(月) 09:19:05> プロパティ自体後付けじゃん…て思ったんだけど、
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 をコンパイルする（＝互換性を持つ）のが難しい。
0584デフォルトの名無しさん
2007/03/12(月) 09:57:09> 仕様策定してる連中がドットを嫌う理由がよくわかんない。
dot 使ったらフィールドアクセスとプロパティアクセスの区別がつかなくなると何度言えば……
0585デフォルトの名無しさん
2007/03/12(月) 10:02:47> どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
ひょっとして、現存するソースコードに Beans のプロパティ持ってるものが
大量にあるって事がわかってない？
0586デフォルトの名無しさん
2007/03/12(月) 11:37:56それとは別に新しい概念を持ち込むのかと思ってたって>>582に書いたでしょう。
何嬉しそうにツッコミいれてんだよ。
0587デフォルトの名無しさん
2007/03/12(月) 11:41:08いや、無知だなぁ、と思って。
0588デフォルトの名無しさん
2007/03/12(月) 11:51:08どの辺が無知だったか教えてちょ。勉強するから。
0589デフォルトの名無しさん
2007/03/12(月) 11:56:57このスレに出てるのだけでも、プロパティに関するリンク先読んでれば
beans と関係のない新しいプロパティを導入するとか思わんでしょ。普通。
0590デフォルトの名無しさん
2007/03/12(月) 13:21:21そうだな。すまんかった。
0591デフォルトの名無しさん
2007/03/12(月) 20:35:44>みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。
ここがよくわかんないんだけど、誰か解説して。
アクセッサがあればそちらを優先的に使う（あるいは逆にフィールドアクセスを優先する）というルールを決めればすむ話じゃないの？
で、583みたいな状況になったらコンパイラが警告を出してくれればそれでいいと思うんだけど。
0592デフォルトの名無しさん
2007/03/12(月) 20:47:38> アクセッサがあればそちらを優先的に使う
それやったらコンパイルが通らん。
> フィールドアクセスを優先する
フィールドでプロパティを上書きできるようになるけど、それで良いんか？
0593デフォルトの名無しさん
2007/03/12(月) 20:56:24○ フィールドでプロパティを覆い隠し
0594デフォルトの名無しさん
2007/03/12(月) 21:00:25> > アクセッサがあればそちらを優先的に使う
> それやったらコンパイルが通らん。
いや、コンパイルは通るかもしれんが……
例えば
> public boolean isDesignTime(){ return designTime; }
は public boolean isDesignTime(){ return isDesignTime(); }
に展開されるから実行時に StackOverflowError 吐いて死ぬ。
0595デフォルトの名無しさん
2007/03/12(月) 21:20:38区別させないのがプロパティだろうに。
0596デフォルトの名無しさん
2007/03/12(月) 21:24:32コンパイラが区別できないって意味なんだけど。
人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。
0597デフォルトの名無しさん
2007/03/12(月) 22:11:17まぁ互換性を維持してのプロパティの導入には実装上の困難を
解決できていないというのはいいんだが、だからといって
「できる方法で実装しちゃおう」となるとしたら賛成できないなぁ。
互換性の面から考えた場合、方法は大きく3種類に分類できて、
1.JavaBeansと相互に互換性のある方法
2.JavaBeansとは互換性がないが、バイトコードレベルでの
仕様変更を伴わない方法
3.バイトコードレベルで拡張する方法
このうち、3.を採用すると何でもありだから議論から除外するとして、
個人的には1.には拘らないから2.でうまいことやってくれないかなと
思うんだが。
0598デフォルトの名無しさん
2007/03/12(月) 23:05:531 の場合はともかく、2 や 3 の場合は コンパイラ実装するとか言語仕様追加する、
とかってのは一番楽な部分だからね。
JavaBeans を切り捨てるってのは、技術的というより政治的な問題だから、
ハッカー気質が強い人ほど、自分でコード書いたりする時間がなくなって
政治的な問題に時間を取られる、って予感があるので手を引きたがる。
2 の場合は機能を欲しがる人は居るかもしれんけど、
（2 をやれるだけの政治的立場とか確保してる人の中で）
やりたがる人は居ないと俺は思うから、たぶん実現できないと思う。
0599デフォルトの名無しさん
2007/03/12(月) 23:18:49切り捨てるわけじゃないか……
でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
標準API とかの setter/getter を新プロパティで置き換えるとかってなれば
厄介な政治的問題だってのは予想できるでしょ。
言語として 2 のプロパティ持ってても、
標準API は 2 のプロパティをサポートしませんとかなったら間抜けだし。
0600デフォルトの名無しさん
2007/03/12(月) 23:26:45こんな決定したら 袋叩きにあうような気もする。
メンテ面倒くさいし。
enum でも、似たような事やってたけどさ。
enum だと、自前の enum を定義するクラスが比較的少ないから
メンテが面倒って不満がそれほど大きくならんかっただけだと思うし。
0601デフォルトの名無しさん
2007/03/12(月) 23:30:420602デフォルトの名無しさん
2007/03/12(月) 23:34:54http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5015403
0603デフォルトの名無しさん
2007/03/13(火) 08:40:52>それやったらコンパイルが通らん。
だから具体的に説明してくれって。頭の悪い俺でも分かるように。
>フィールドでプロパティを上書きできるようになるけど、それで良いんか？
これが問題になるのって、フィールドがnon privateのときだけだよね。
フィールドもアクセッサもpublicというのはちょっと考えにくいから、これでも別にいいと思うけど。
>>594
>例えば
>> public boolean isDesignTime(){ return designTime; }
>は public boolean isDesignTime(){ return isDesignTime(); }
>に展開されるから実行時に StackOverflowError 吐いて死ぬ。
これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これなら大丈夫じゃない？
0604デフォルトの名無しさん
2007/03/13(火) 09:35:33> これが問題になるのって、フィールドが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 は区別してないし。
0605デフォルトの名無しさん
2007/03/13(火) 09:38:13> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
> これなら大丈夫じゃない？
package-private もしくは protected な フィールドと、
public なプロパティで問題起こるから解決になってない。
0606デフォルトの名無しさん
2007/03/13(火) 10:13:00> 覆い隠しって単純名だけに作用するんじゃないんかな？
違うか。覆い隠しじゃなくて、隠蔽されたフィールドは継承されないから、
B のインスタンスからは A の field にはアクセスできないのか。
名前の章ばっかし見てたら理解できんかった。
0607デフォルトの名無しさん
2007/03/13(火) 10:17:350608デフォルトの名無しさん
2007/03/13(火) 12:25:260609デフォルトの名無しさん
2007/03/13(火) 13:47:17> 展開させるのは 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; }
}
とかがコンパイルエラーになる、と。
0610デフォルトの名無しさん
2007/03/13(火) 15:00:26(this).bar とかだと どうすんだろ？
0611デフォルトの名無しさん
2007/03/13(火) 16:53:37・フィールドが可視ならフィールドアクセス
・そうでなければ、プロパティがあるならプロパティアクセス
とかの方が良いような気もする。
それでも static なプロパティを許したりすると、同名のメンバークラスと衝突するし。
ってか、同名のフィールドが可視なら shorthand syntax for accessing properties
を使えないのって、本当に使いやすいかも結構問題のような？
0612デフォルトの名無しさん
2007/03/13(火) 19:42:20ttp://download.java.net/jdk7/binaries/
0613デフォルトの名無しさん
2007/03/13(火) 19:42:27>違う
というのは勘違いということでいいのかな？
>そうだよ。だから無理だって言ってるじゃん。
だから『 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく』といっているんだけど。
>そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
0614デフォルトの名無しさん
2007/03/13(火) 19:48:30＞なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
汚い設計。
わかりにくいです。
あとマルチスレッド周りで問題がでそうだな。
0615デフォルトの名無しさん
2007/03/13(火) 20:05:41> というのは勘違いということでいいのかな？
いや、覆い隠しは勘違いだったけど、
private フィールドで public なプロパティを隠蔽できるから問題になるのは変わらない。
> 区別してないなら区別すればいいじゃん。
区別しても、 >>605、>>609、>>610 みたいな穴があるから、やるだけ無駄。
0616デフォルトの名無しさん
2007/03/13(火) 20:44:57どっちかっつーと dot でプロパティアクセス許す場合、
フィールドと同名のプロパティを作れるってのが混乱の元だとか認識されてんのかも？
0617デフォルトの名無しさん
2007/03/13(火) 20:51:03問題でるかな？
0618デフォルトの名無しさん
2007/03/13(火) 20:53:23> なんで無茶なの？
根本に近い方のルールを書き直すってのは、
既存のコンパイラを改変する時に多くの労力がかかりそうだってのは分かるでしょ？
だから無茶なの。
0619デフォルトの名無しさん
2007/03/13(火) 21:20:36> ${classInstance.propertyName} みたいに ${} で括った部分では
> 式言語使えるようにすりゃええやん、ってのも出てるけど……
ksl の 課題追跡にあった
https://ksl.dev.java.net/issues/show_bug.cgi?id=2
に似てるっちゃ似てるかも。
でも、ecmascript みたいに Java と同じく } でブロック終了する言語だと
対応とるの大変そうだなとか思った。その辺は EL だと楽だけど。
0620デフォルトの名無しさん
2007/03/13(火) 21:34:43Velocityが標準になるみたいな感じだが。
0621デフォルトの名無しさん
2007/03/13(火) 22:29:53要は、今の仕様で
private int xxx;
というフィールドと
public int getXxx()
というメソッドが混在できる以上、フィールドの延長上のプロパティと
getter/setterの延長上のプロパティとは相容れないわけだ。
いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
関係もないことにすりゃ、それで解決すると思うんだけどね。
0622デフォルトの名無しさん
2007/03/13(火) 22:49:49> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決すると思うんだけどね。
仮に、それをやっても「解決する」のは言語仕様の問題だけで、
ライブラリ＆フレームワーク＆ユーザーコードの方に問題を押し付けてるのような。
それなら、ぶっちゃけ新しい言語作っちゃった方が速いと思う。
0623デフォルトの名無しさん
2007/03/13(火) 23:18:12上の方でだれか言ってたけど、フレームワークのプロパティとは無関係な「Java言語プロパティ」
を作ってもいいんじゃないか。紛らわしいなら名前は変えてもいいけど。
そもそもなんでプロパティ構文が欲しいんだ。ドットネットが羨ましいんだろうか。
0624デフォルトの名無しさん
2007/03/13(火) 23:24:53「問題」って、どんな問題かな？
別に既存コードの変更が迫られるわけじゃないっしょ？
0625デフォルトの名無しさん
2007/03/14(水) 00:09:08むしろstructが羨ましいんじゃないか？
0626デフォルトの名無しさん
2007/03/14(水) 02:48:40互換性を確保しつつ新プロパティを使おうと思ったら、
既存のプロパティと、新プロパティの両方管理しなきゃいけなくなる。
二重のコストを払う必要が出るんだから、普通は問題になる。
おまけに、フレームワークやライブラリが二重のコストに耐えかねて
既存のプロパティを捨てたら、やっぱり既存のコードを書き換える必要が出る。
直接コードの変更を迫ってないだけで、間接的にコードの変更を迫ってる。
0627デフォルトの名無しさん
2007/03/14(水) 07:18:35プロパティが導入されたからといって、既存のコードを無理に
対応させることはないでしょ？別物なんだから。
それに例えば、ジェネリクスが導入されたとき、それに対応して
書き換えられたフレームワークはあったし、もちろんそれを利用
しているユーザーコードも書き換えられることがあったけど、
それは別に変更を余儀なくされて行ったわけじゃないよね？
0628デフォルトの名無しさん
2007/03/14(水) 07:52:01> それに例えば、ジェネリクスが導入されたとき、それに対応して
Generics の場合は「JavaBeans とは無関係なプロパティ」導入と違って、
例えば Collection フレームワークを Generics対応に書き換えたら、
互換性が完全に無くなるってわけではなかったけど、
「JavaBeans とは無関係なプロパティ」の場合は、
「JavaBeansのプロパティ」のサポートをうちきれば互換性が無くなるし。
例えるなら enum の方が近いな。int enum と typesafe enum の両方を提供してるAPIがあって。
それにはコストがかかる。int enum だけ、typesafe enum だけを提供してるAPIもあるけど、
プロパティの場合は影響範囲も、統一的に扱う必要性も enum の時より大きいから
両方の提供がより大規模に起こるのは容易に想像できる。
「JavaBeansのプロパティ」と「JavaBeans とは無関係なプロパティ」は共存可能って話なんだろう？
互換性維持のためには「JavaBeansのプロパティ」が必要で、
新機能対応のためには「JavaBeans とは無関係なプロパティ」が必要で、
それを両方管理しようとすりゃコストはかかる。問題になるだろ、普通は。
0629デフォルトの名無しさん
2007/03/14(水) 08:10:26例えば、p=a.getXxx()をp=a.xxx、a.setXxx(p)を a.xxx=pとか。
0630デフォルトの名無しさん
2007/03/14(水) 08:37:50それだと dot でやるのが面倒。
既存の getter/setter に使われてる「プロパティの名前」と
同名のフィールドが存在可能だから。
0631デフォルトの名無しさん
2007/03/14(水) 08:39:25そのコストってのもフレームワークの作者とかはともかく開発者は関係ないね
0632デフォルトの名無しさん
2007/03/14(水) 08:44:16何より、無駄にバグのリスクが増えるし、
標準APIとかでドキュメントの翻訳に時間がかかるようになるとも考えられるね。
0633デフォルトの名無しさん
2007/03/14(水) 08:45:07開発者というより、末端ユーザだな
0634デフォルトの名無しさん
2007/03/14(水) 09:10:34a.xxx と同名のフィールド a.xxx があった場合、扱いが面倒。
互換性を考えるなら >>611 あたりのルールが落としどころかとも思うけど、
public な同名のフィールド使えば、プロパティに触れなくする事ができたりするし、
完璧とはいいがたい。
言語仕様に書く文言も相当慎重に選ばないと、
デフォルトパッケージのクラスが import 出来なくなったみたいに、
言語仕様の文言から副作用がでる可能性も……
もっとも、import の方は意図しない副作用なのか意図的なものか、
ちゃんと知らんのだけど。
0635デフォルトの名無しさん
2007/03/14(水) 12:24:270636デフォルトの名無しさん
2007/03/14(水) 12:37:32Genericsは、既存の一般コードに関しては意味の変更なく使えたぞ
>>632
さすがにそのコストを考えるのは臆病すぎｗｗｗ
>>635
マルチコア対応って一体何なのか分からない。
なぁ、何でみんなdotにこだわるの？
別の記号にして、定義も全く別にすればスッキリ導入なんだけど？
バイトコードは拡張しないと駄目だろうけど。
0637デフォルトの名無しさん
2007/03/14(水) 12:48:08> 別の記号にして、
dot 以外の記号はキモイから嫌らしい。
> 定義も全く別にすれば
既存の資産と協調して使えないので、導入しても嬉しさ半減。
> バイトコードは拡張しないと駄目だろうけど。
バイトコード拡張は必要ないでしょ。
クラスファイル仕様は弄るかもしらんけど。
0638デフォルトの名無しさん
2007/03/14(水) 12:50:02マルチCPU対応のVMだったら、マルチコアも そのまま使えるんじゃない？
ってか、マルチコア対応を言語にのっけるってどーやるんだ……
0639デフォルトの名無しさん
2007/03/14(水) 13:13:07JavaBeans使ってたんだろうか？
結局JavaScriptObjectのプロパティからアクセスしようとした時JavaObject側にxxxってフィールドがあると衝突して使い物にならないから
LiveConnectには元々ない後付けされた機能なんて不完全だって言われてたな・・・。
オライリーのサイ本にも指摘されてたような。
0640デフォルトの名無しさん
2007/03/14(水) 13:39:56阿呆だな。もっと簡単な問題があるよ。
>>624
JavaBenas のプロパティと別のプロパティなわけでしょ？
標準API とかの既存の interface に abstract な property を追加したら
既存のコードの中で、そのinterface を実装してて JavaBeans とは別のプロパティを
実装してないクラスがあれば、互換性に問題が出る。
互換性に配慮したら interface に迂闊にプロパティ追加できない。
それだと、たぶん使い物にならない。
0641デフォルトの名無しさん
2007/03/14(水) 13:48:02具体的に言えば 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 のプロパティと別の新プロパティを導入しても、
あんまし使い勝手がよくないだろうね。
0642デフォルトの名無しさん
2007/03/14(水) 14:10:45結局 ->案が一番妥当だろう。
プロパティを定義する側はこれまでどおりgetXXX/setXXXを使用する。
プロパティを使用する側はgetXXX/setXXXと->XXXの両方が使える。
フィールドにXXXがあっても問題なし。
しかし、この程度のものならいらないな。
0643デフォルトの名無しさん
2007/03/14(水) 15:29:22だよな。
いらないと思うよな。
0644デフォルトの名無しさん
2007/03/14(水) 15:41:270645デフォルトの名無しさん
2007/03/14(水) 15:47:49今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入するのだったらその書き換えはいらないよね？
0646デフォルトの名無しさん
2007/03/14(水) 16:03:21だから、>>641 は
> 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入
した場合に発生する問題だってば。
今Beansで「プロパティ」と呼んでいるもの、
要するに setter/getter呼び出す syntax sugar として
accessing properties な構文を入れるなら、>>641 の問題は発生しない。
0647デフォルトの名無しさん
2007/03/14(水) 16:36:28なんで書き換えようとするの？そのままにしとけばいいじゃん。
0648デフォルトの名無しさん
2007/03/14(水) 16:56:32>>641 をちゃんと読め。
0649デフォルトの名無しさん
2007/03/14(水) 17:45:12ちゃんと読んでもわからないです。
何故 interface DesignMode に property designTime を追加してるの？
ひょっとして俺ｽｹﾞｰアホなこと訊いてる？
0650デフォルトの名無しさん
2007/03/14(水) 18:38:36うん。
0651デフォルトの名無しさん
2007/03/14(水) 22:27:50あきれる。
isXXX()/getXXX()をgetterのインターフェースに用いたままプロパティを
実現しようとすることに問題があるから別のインターフェースを採用
しようという話なんだから、その例でinterfaceの方にisDesignTime()を
追加するという仮定自体がそもそもありえないし、仮に追加しても
何の影響もない。
0652デフォルトの名無しさん
2007/03/14(水) 22:35:24■ このスレッドは過去ログ倉庫に格納されています