- 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/
- 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 と同文、と。
- 678 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 11:15:13 ]
- > 標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
標準API は、既存の setter/getter を置き換えるものも含めて、
極力 abstract な新プロパティを追加しない方向になるだろうから
うーむ。既存の setter/getter は互換性のために残す事を想定してるから
置き換える、じゃないんな。まぁ、setter/getter を残しても残さなくても、
標準API に abstract な新プロパティを追加すれば同じだけど。
- 679 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 20:13:04 ]
- ゲーム関係に力を入れてけば自然とデスクトップ周りが強化されるからそっち系だな
OSを選ばないUDIライブラリとか、BGM周りはネイティブにディスパッチとかね。
標準であるかどうかってのがここらへんは大きい。
- 680 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 22:34:05 ]
- まずジョイパットか
- 681 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 23:05:33 ]
- ジョイパッドサポートは地味に大きいな
って10年前からいわれてるが
あとはJOGLも標準ではいってくれるといいのだが
今はプラットフォームごとに用意してあげないといかんからWindows以外はめんどくさい
本当は新世代専用GCコールもほしい
タイミングコントロールできて殿堂入りしないやつならアクション系もバリバリ使える
- 682 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:05:01 ]
- >>677
interfaceに追加したらそれを実装するクラスに影響があるのは、
「プロパティ」に限らず抽象メソッドでも同じだわな。
既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
↓
だから標準APIに「抽象メソッド」は追加できない
↓
「抽象メソッド」は標準APIに使えないから無意味
あほか。
- 683 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:22:54 ]
- >>682
> 既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
普通は、既存の interface に抽象メソッド追加するのは慎重にする。
逆に、 今までにない interface を作る時は自由に抽象メソッドを定義できる。
> 「抽象メソッド」は標準APIに使えないから無意味
安易に追加できないが、「使えない」とか「無意味」とはならない。
abstract な新プロパティも、抽象メソッドと同じで、
今までにない interface を作る場合は自由に定義できるだろうけど、
既存の interface に追加する場合は慎重にならざるを得ないだろう。
既存の interface 経由で使えない事が予想される新プロパティは
「使えない」とか「使い勝手が悪い」と言える。
- 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
普通は説明されなくてもわかるだろ。あんなの。
気づかない方が頭がおかしいんだよ。
|
 |
