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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 23:17 / Filesize : 271 KB / Number-of Response : 965
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
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 と同文、と。
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
普通は説明されなくてもわかるだろ。あんなの。
気づかない方が頭がおかしいんだよ。
711 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:35:01 ]: >>710
「普通」とか言うけど、「使い勝手が悪い」っていう結論は主観が入り込んでるだろ？
712 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:10:42 ]: ->で全然問題なし
713 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:28:20 ]: >>713
どうでもいーけど長文ウザイ
715 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:20:14 ]: 説明が下手なんだからしょうがないよ。
716 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:22:41 ]: 説明されなくたって、既存のプログラムに新機能を追加して、
どんな影響が出るかを予見できないってのは技術者として拙いだろ。
717 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:30:57 ]: じゃあレスする必要ないじゃんｗ
なんで一生懸命説明してんの？
718 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:33:03 ]: >>716-717
次世代Javaと関係ない話題だな。続きは他所行ってやれ。
719 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 12:59:19 ]: >>718
たった2レス程度で…気が短いな
720 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 16:16:28 ]: >>713
結局、getHoge()/setHoge()を使わない新プロパティシステムを導入しても、
既存のgetHoge()/setHoge()を使えないから使い勝手が悪いということかw
721 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:14:19 ]: ふー、びっくりした。でも、反対派の意見はほぼ一点に集中している。
プロパティは既存の言語機能と干渉するから、導入の必要はないというもの。
それ、ほんとなのかなあ（ｒｙ
722 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:44:26 ]: サイレントマジョリティの声を尊重してプロパティを導入することにしました。
当然のことだよね
723 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:51:13 ]: >>721
既存の言語機能と干渉とかいう以前に、そもそも「そんなに必要な物なのか」って
ことがまずあるんじゃないか？

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

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

ちなみに個人的にはgetter/setterの使用側は今のままで十分。
ただ、定義するのが面倒だから、アノテーションとかで自動でデフォルトのgetter/setterが
作成される仕組みができるぐらいでも満足だよ。
724 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 02:14:53 ]: a = obj get foo;
obj set foo = 1;
725 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:54:34 ]: >>722
>>667 の結果を見るに、
プロパティ要らないって意見の方がサイレントマジョリティで、
プロパティ欲しいと言ってる方が、声の大きい少数派。
726 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 11:47:22 ]: >>721-722はネタなんで相手しなくていいです
727 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 12:23:09 ]: >>724 はネタじゃないのか……
728 名前：724 mailto:sage [2007/03/19(月) 20:34:17 ]: >>727
ネタです。
729 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 23:15:19 ]: >>723
うむ。
プロパティ自体は特にそんなに欲しいものでもないが、自分で開発していて
コードの半分以上が意味のないgetter/setterで占められているクラスが
山のようにあるのを見ると、何かが間違ってる気がしてならない.。
730 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 23:21:52 ]: あるBeanのプロパティ値ともうひとつのプロパティ値を足し算してその結果を格納とかめんどくさすぎ
同様にBigDecimalの演算もきっつい
731 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 00:51:51 ]: >>730
プロパティに足し算して格納とかってそんなに使う？
俺、WEB開発系がメインだけど、プロパティに対して加算とかって
ほとんどしたことないし、BigDecimalも使ったことない。

きっとプロパティが必要な分野と、たいして必要とされない分野があるんだろうな。
732 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 01:17:10 ]: getHoge()がめんどくさいから->でやらせろって言ってる人は、
やっぱりadd()がめんどくさいから演算子オーバーロード使わせろ
とか言うのかな。
733 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 02:00:33 ]: BigDecimalは業務系はこれしか使わないというくらい使う
BigDecimalだけはStringのようにシンタックスシュガーとしてaddとかやってほしいな

プロパティの足し算引き算ってのは普通にあるっしょ
金額とか在庫とかいくらでも
特にO/RマッパやBeanBinding関係使うと頻発
734 名前：しろうと mailto:sage [2007/03/20(火) 09:36:43 ]: public class Foo {
　　public int bar;
}

じゃだめなん？
735 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 10:15:22 ]: セット時やゲット時に加工が出来ないからダメ
それに定義のほうはどうにでもなるためたぶん問題になってない
736 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:24:23 ]: VMがグリッドコンピュータに対応するのはいつだ？
737 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:34:18 ]: VMがグリッドコンピュータのネイティブな基盤になればいいのに。
738 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:38:44 ]: 設定がないと動かないJVMは面倒だな。

グリッドとかは、アプリケーションの下で何らかのグリッド制御部が
動いていて、JVMのリソースとしてグリッドが見えるって前提だろうから
MVMが実現して、アプリケーションの起動とJVMの起動が分離するまでは
あんまり興味がないね。
739 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 23:23:42 ]: クラスタ用OSとしてのJVMなら
BEAだかが仮想化技術として構想を発表してたはず
740 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 23:27:12 ]: >>738
グリッドが見えるのを前提にする必要はないでしょう。
HotSpotが全自動で動的最適化を行うように
グリッド制御部が全自動でスレッド分散を行うのが
あるべき姿だと思います。
741 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 22:20:18 ]: JDK7 build10
download.java.net/jdk7/changes/jdk7-b10.html
download.java.net/jdk7/binaries/

NewFeatureは地味なパフォーマンス向上と
getAsText,setAsTextか。これはちょっと嬉しいな。
742 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 05:37:51 ]: グリッドより先にjavacがメニーコアをフルに使用するための中間コード
を生成することになることが重要。
PGがthreadを手書きしてでしか対応できないというのではコストがかかりすぎる。
743 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 13:15:00 ]: プロパティの話に戻りますが、
やっぱ、何か明示的にプロパティを示す構文がほしい。
と思ったのは、eclipseでリファクタリングするとき。
getter側をリネームしたら、setter側も変わってほしいし、名前の定数も変わってほしい。

public static final string PROPNAME_XXX = "XXX";
public Object getXXX() { ... }
public void setXXX() { ... }
の三者の一貫性を、自動的に保ちたい。
なんか、アノテーションつけとくと、eclipseが、それをヒントに一括リネームしてくれる
だけでもいいんだけど。
744 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:16:16 ]: それはプロパティ構文あってもなくてもあんまり変わらないのでは。
745 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:25:33 ]: >>743
getter/setter はまだしも、
> public static final string PROPNAME_XXX = "XXX";
の必要性が良く分からん。
746 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:42:25 ]: 俺もその部分が？だな
名前だけで型がないし、そもそも型が要らないならenumでいいし
まさか、文字列の中身がクラス名とか
747 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 15:40:52 ]: >>745
>>746
プロパティ名を変えるときに、プロパティ名の文字列リテラルがソース中に散らばってると、
修正がめんどくさいから。
IDEの完全一致文字列リテラルの置換でできなくはないけど、"item"、"count"なんてプロパティ名
だと、無関係な文字列に誤爆するかもしれん。
748 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 17:01:43 ]: >>747

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

得てしてこういう理由で出てくるワークアラウンドは
引きずらない方がいい悪習慣である可能性が高い
749 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:16:31 ]: C#は詳しくないが、プロパティ名を変更したとき、
そのプロパティを実際に使用している箇所の変更は不要なの？
751 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:26:01 ]: private int myVar;
public int MyProperty {
get { return myVar; }
set { myVar = value; }
}
752 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:03:02 ]: >>747
それはわかるが>>743のコードはカス
>>751のようにすべきかと
754 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:15:07 ]: >>743
PROPNAME_XXX って firePropertyChange 関連以外で使う？
755 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:48:38 ]: >>751
C#構文をそのまま持ち込んだらこうなるな。
欲を言えば、myVarとMyPropertyの関係(というか変数実体についての記述)を
何らかの形で示すことができて、省略時はデフォルトsetter/getterが呼ばれる
ようにできたらとC#より便利になると思うんだけどね。
つまり、アクセスをフックしたり禁止したりする場合だけ明示的に記述する。
＃C#の場合はgetter/setterを省略した場合はアクセス不可
756 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 00:42:52 ]: プロパティと変数なんて一対一になるとは限らないじゃん。
757 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 01:14:48 ]: もちろん絶対必要というわけじゃなくて、プロパティの型と同じ、実体となる
フィールドを指定すること*も*できるってんならいいんじゃない？
758 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 08:18:58 ]: プロパティなんぞいらん。糖文増やしてどうすんだよ。
759 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 12:29:55 ]: >>751みたいなので普通にいいんじゃね？
getとsetのメソッドやら先頭を大文字推奨、プロパティとしては小文字扱いとか
現状のほうがややこしいだろ
getとsetがばらばらにおかれることによって見通しが悪くなる場合もあるし
リファクタリングの問題もある

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

現状のままが最悪だよ
760 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 13:44:08 ]: >>751
そっから .NET に倣って、 set_プロパティ名 get_プロパティ名ってメソッドに展開される、と？
761 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 02:49:13 ]: private int myVar;
public get int myProperty() {return myVar;}
public set void myProperty(int value) {myVar = value;}

JavaScriptライクにこれでおｋ。
762 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:11:32 ]: getとsetを予約語にせずに実現できるならね。
763 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:31:48 ]: 予約語にしたらまずいん?
764 名前：デフォルトの名無しさん [2007/03/30(金) 05:45:23 ]: getやsetを変数名とかに使ってたらどうするんだよ？
765 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:49:20 ]: そんなに互換が大事ならシンタックスシュガーなんていらないだろｗ
むしろIDEに機能として組み込めよ
766 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 07:07:49 ]: >>764
5.0になったときも非互換変更あったじゃん
そのためにコンパイラの文法バージョンを指定するオプションがあるんでしょ
767 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 07:33:32 ]: @prop(setter="on",getter="on")
private String str;
で
XX.setStr("A");
XX.getStr();
がコンパイルとおる、でなにがいかんのかと（ry
768 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 09:52:12 ]: >>764
@Set、@Getにすればいいよ。
769 名前：デフォルトの名無しさん [2007/03/30(金) 11:45:38 ]: ブロックにアノテーションつけられないんじゃないっけ
770 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 11:54:29 ]: @getter("getValue");
@setter("setValue");
private String value;

これでいーよ。
771 名前：デフォルトの名無しさん [2007/03/30(金) 11:56:08 ]: ブロックとは？
772 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 12:12:16 ]: objective-pascal 方式

@setter("__value") @getter("__value") public String value;
private String __value;
773 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 14:36:20 ]: >>761
に一票。
assertだって使ってた奴いたんだから構わんよ。
というか、get、setっていう変数はなさそうだし、あとに何も付かないset,getメソッドも
そんなに無いだろうからいいよ、それで。
774 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 19:29:56 ]: >>751
のほうがまとまってていいな
776 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 19:35:36 ]: 新記法のプロパティ定義は使い勝手が良くないから駄目だって、
説明の下手なおじさんが上の方で散々教えてくれてるのに。
777 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 21:55:01 ]: >>751みたいなC#方式はvalueが予約語になるのが個人的には嫌だ。
778 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:12:44 ]: >>777
C# みたいな文脈依存の予約語なら、value が使えないのは set {} 内だけだし。
779 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:32:27 ]: 別にそのままにしてなくてもいいだろ
private int myVar;
public int MyProperty(value) {
get { return myVar; }
set { myVar = value; }
}
とか
780 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:45:47 ]: > public int MyProperty(value) {
……。そっちに付けるか
781 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 23:50:18 ]: こんな案もあるんだから、もっとアノテーション使いまくりでいいんじゃねぇの？
今のアノテーション仕様にとらわれる必要はないよ。
journal.mycom.co.jp/articles/2006/11/01/jsr308/
782 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:02:40 ]: アノテーションでコンパイル制御できるようにならんかのう。
ディレクティブは邪道だから駄目か
783 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:50:04 ]: >>776
説明だけが下手なんだったら良かったが、論理展開も
おそらく頭の中も下手だったからな。
784 名前：デフォルトの名無しさん [2007/03/31(土) 06:33:25 ]: 日本語でおｋ
785 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:08:46 ]: >>779
これ今の文法だとgetの後に;が無いって怒られるじゃない
普通のメソッドの中でも {}　でスコープを制限する記法があるから
やっぱ普通のメソッドじゃないという何らかの記述は必要。

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

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

アノテーションは、あくまで付加的な情報であって
文法の指定であって欲しくはない。
786 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 11:32:15 ]: >>782

コンパイル制御させたら地獄のIFDEFの復活になりそうなんだが…。
787 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 12:43:15 ]: >>786
でも C# には ConditionalAttribute あるよ
788 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:54:10 ]: >>785
プロパティ構文実装しようとしてる時点で
現行の文法でとおらないというのは意味のないことだな

propertyの予約語に関しては影響範囲はたぶんenumよりは少ないと思う
enumはつかわれまくってたからなぁ
789 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:09:44 ]: >>787
過去の言語を十分に研究して作成した言語でも言語設計の失敗はある。
790 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:13:51 ]: C♯には #if もあるわけで
791 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:55:34 ]: >>785 >>788
ちっとは勉強した方が……

blogs.sun.com/ahe/entry/java_se_7_wish_list
の Shorthand syntax for declaring properties のところに、
この構文なら property はキーワードにする必要が無いって書いてある。

weblogs.java.net/blog/forax/archive/2007/01/a_property_prop_1.html
の prototype-1.7-b05.jar 試してみれば分かるけど
property を言語全体に影響する予約語にする事無く、property でプロパティの定義させてる。

常に予約語にする必要がないってわけじゃないけど、
導入する構文によっては予約語にする必要はない。
もしくは、予約語にしないように導入する構文を慎重に決める必要がある。
792 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:00:14 ]: 予約語にしたほうが構文解析が楽とか紛らわしいのがなくなるとかメリットもあるから
単純にはいえんよ
793 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:17:48 ]: >>789
なんか一言で失敗作呼ばわりされてしまったなぁｗ
794 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:40:08 ]: >>792
「property を予約語にしない」ってのを選択肢として持ってないのは不勉強。
795 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:58:51 ]: 勉強厨か
上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ
gotoだって使わないが予約語だし、newだって予約語にしなくても本当は使えることは使える
796 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 18:01:38 ]: > 上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ
既出。
797 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:18:57 ]: >>796
「既出。」だけのレスは2ch不勉強
798 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 23:32:26 ]: propertyっていう変数は、結構使われてると思うけどな。
799 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 11:57:31 ]: >>792
紛らわしさって？

property を予約語にしない場合の紛らわしさって言っても
せいぜい property property が出来るぐらいだと思うが。
800 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:05:25 ]: ×property property が出来る
○class property がある時に property property property が出来る

もっとも、>>785 も >>788 も具体的な構文規則も例も書いてないから、
>>785 >>788 の脳内構文で出来るのかは知らんけど。
801 名前：デフォルトの名無しさん [2007/04/01(日) 15:41:45 ]: >>781
前にGenerics使うと長くなるからtypedefいるだろとか言ってたC++信者がいたが
これはほんとに可読性に問題起こしそうだな……
どうにかならんもんか
802 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 15:52:49 ]: >>801
blogs.sun.com/ahe/entry/java_se_7_wish_list

Type aliasing
Shorthand syntax for declaring local variables
803 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:57:04 ]: >>802
結局は、独自定義があるとそれによって可読性が落ちるかもしれないから
適用範囲に十分注意ってとこだな
804 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:00:26 ]: Ada風に別名を付けるときに元の型から値の有効範囲縛れるように出来ると良いな。

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

typedef month byte 1...12;

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

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

キャストは値の範囲が大きい方から小さい方の場合は代入されている値が小さい方で表せる範囲の場合のみ、または小さい方から大きい方。
805 名前：デフォルトの名無しさん [2007/04/01(日) 18:12:17 ]: >>804
それこそアノテーションでいいんじゃないか？
806 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:34:49 ]: >804
飽和演算もほしくなるな
807 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:52:21 ]: JavaBeansのフィールドやセッターにアノテーションってのが現実的だな
範囲外がきたとき例外出すのか、飽和させるのか、値を変えないのかの判断もいれればグッド
ついでに一番面倒なプロパティリスナのfireも自動でやってほしい
808 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 21:53:14 ]: >>807
その情報を元にWebアプリ側で自動でバリデートやエラーメッセージ出してくれたら最高に楽だな。
809 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:05:41 ]: >>808
なんかライブラリとNetBeansでプラグイン作りたくなってきた
GUIとのバインディングでもかなり効率よさそうだしな
810 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:41:26 ]: プロパティなど要らぬ！
構文糖・即・悪こそが我々Java厨の共有する唯一の正義ではなかったのか！

それを捨てるというならば、まずtypedefを導入しやがれ
811 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:14:33 ]: Genericsは構文糖じゃねーのかよ
生成されるバイトコードはキャスト使いまくりのものと同じだろ
812 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:28:04 ]: >>810
そんなもん、EoD とか言って autoboxing みたいな構文糖が入った時点で捨てとるような。
813 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 00:10:56 ]: >>811
乙
814 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 11:11:13 ]: >>810
何かいまいち語呂が悪いな

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

copy(Cloneable obj)とかif(obj instanceof Cloneable){/*処理*/}とかそういうことは出来なくなるけど……
816 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 19:40:24 ]: いやtypedefは欲しい。
Javaで導入されていないのは、sourceが読みにくくなるという理由だろうけど。
817 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:04:57 ]: typedef String MyString;
みたいなのは同じ型の別名を作るだけだから有害だが、
typedef Map<String, List<MyClass<Integer, String>>> MyType;
みたいなのは特別な組み合わせに特別な名前をつけているから有用だと思う。

だから、Genericsありの場合のみtypedefを許すというのはどうだろうか。
818 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:12:11 ]: class MyType extends Map<String, List<MyClass<Integer, String>>>{}
819 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:31:09 ]: >>816
実態が変わるのならきっついのでは？
Javaはすべてダイナミックリンクなわけで
Stringからchar[]への変更とかIntegerからLongへの変更とか現実的ではないし
820 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:38:01 ]: これさー

typedef String MyString;
MyString abc = "sample";

これ、OK にするん？　NG にするん？
821 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:44:12 ]: >>818
それでいけるかー

typedefのためだけにファイルいっこつくるのが許容できるかどうかだな
822 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:51:09 ]: >>821
逆にファイル一個作らない場合、どのソースファイルに記述するか迷わないか？
ひとつのクラス内でのみ使用するというならいいが。
823 名前：デフォルトの名無しさん [2007/04/03(火) 21:53:30 ]: >>818
擬似Typedefアンチパターン
www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml
824 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:27:37 ]: extendsに関してはあまり的を得ているとはいえない批判だな。
公開APIで使うべきではないけど、内部処理で使うには問題はなかろう。
「大規模では・・・」というのも、モジュール境界で使わなければいいだろう。
825 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:33:36 ]: >> 820
OKだろ。
826 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:59:03 ]: >824
当を得る、的を射ると書こうと思ったが
"的を得る"もあながち間違いとはいえないらしい
827 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 23:09:14 ]: >>820
そんなん言語仕様作ってる連中が居るところで聞かなきゃ意味がない。

どーせやるなら generics のパラメタ型だけじゃなくて
JSR 308 の型へのアノテーションも含めて欲しいけど。
828 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 23:35:42 ]: typedef派の諸君！ Java7で何かが変わると思ったら大間違いだ！
所詮dolphinなんか、property派のお祭に過ぎない！
我々typedef派にとってdolphinほど馬鹿馬鹿しいものはない！
多数決で決めれば、property派が勝つに決まってるじゃないか！
829 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:16:01 ]: 俺は言語使用云々よりもMVMが最も重要だと思う。
MVMさえ実現されれば、デスクトップJavaもサーバJavaもかなりの勢いで道が開ける。
830 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:44:35 ]: 俺もそうは思うが、MVMって実装される予定はあるのか？
831 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 01:12:55 ]: >>828
俺はビビらない

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

>>830
俺がずっとヲチしてるとこは年単位で動きナス
ttp://research.sun.com/projects/barcelona/
ttp://java.sun.com/developer/technicalArticles/Programming/mvm/
唯一怪しげな情報として引っかかってきたのが
ttps://jvmcomm.stage.dev.java.net/
ここによると、MVMは作られた、とのこと。
もしかして、通常権限だとアクセスできない
ttps://mvm.dev.java.net/
に何らかの情報が？誰か触った事のある奴居ないっすか？
832 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 08:41:27 ]: >>823
いい記事を知った
㌧
833 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 09:33:04 ]: >>828
クロージャー祭りなワケですが。
834 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 11:59:58 ]: 諸君！この言語は最悪だ！
プログラミングだとかコンピュータだとか、
私はそんなことには一切興味がない！

あれこれ改変して問題が解決するような、
もはやそんな甘っちょろい段階にはない！
こんな言語はもう見捨てるしかないんだ、
こんな言語はもう滅ぼせ！

私には、建設的な提案なんか一つもない！
今はただ、スクラッチ＆スクラッチ、0から書き直すことだ！
835 名前：デフォルトの名無しさん [2007/04/04(水) 13:45:51 ]: MS儲おつかれさまです。
836 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 20:03:09 ]: MVMなんかいくら待ったって無駄だっ！
837 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 01:17:46 ]: >>835
うん、MSは儲かるよ
838 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 07:55:41 ]: 外山ゲイツ
839 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 20:20:00 ]: JDK7 build11
download.java.net/jdk7/changes/jdk7-b11.html
download.java.net/jdk7/binaries/

何か地味なビルド。
OpenJDKでのビルド修正に関するFixばかり。
840 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 15:01:43 ]: NIO2 の草案できたらしい。
d.hatena.ne.jp/kazama/20070413 より。
841 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 21:03:32 ]: すげー
日本語版が用意されているという趣向が
ちょっと見てみようかという気になる
842 名前：デフォルトの名無しさん [2007/04/18(水) 12:27:47 ]: 進歩してるなｧ
journal.mycom.co.jp/articles/2007/04/11/openterracotta/index.html
843 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 20:17:38 ]: JRE仮想化はBEAみたいなハードウェアよりなのが勝つんじゃないかな
844 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 20:53:59 ]: ところでJavaでCPUのコア数って取得できましたっけ？
845 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 21:06:02 ]: >>844
次世代関係ないな。初心者質問スレいけ。
846 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 08:13:46 ]: 知らないなら知らないって言えばいいのにｗ
847 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 21:58:33 ]: JOGLがSEに組み込まれることと、
Uniform Driver Interface対応がされれば
Javaクライアントの未来もあるんだが、
今だサーバ関係ばっかサポートしてるな。
848 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 22:03:55 ]: JavaSE6でJOGLとの融合する予定だったけど不安定でとめたからな
今のバージョンでOpenGLレンダリングでGLJPanel使うとよくおちる
5.0はまともにレンダリングされなかったけどな
なんかリペイントマネージャがおかしかった模様

JOGL＋GLCanvas自体は安定してるのでゲームでは問題ないけど、
GLJPanelが動くようにならないと復権無理だな
あとは入力インターフェースとして2軸2ボタンでいいのでジョイパッドの正式サポートを
849 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 23:13:54 ]: 「New」IO「2」か。。。どれだけ計画性のないネーミングだっつーの
850 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 23:31:50 ]: >>849
NIO2は別名なんだろ？
統合か名前が変わるかするだろう
851 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 10:36:48 ]: >>849
サントリー New Old
852 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 12:39:51 ]: >>851
あれはわざとやったらしいよ
853 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 23:37:33 ]: マトリックスの奴の名前だっけか
854 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 00:43:10 ]: >>853
仁王？
855 名前：デフォルトの名無しさん [2007/04/28(土) 06:15:28 ]: 言語レベルでの複素数型のサポートっていつやるの？
856 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 09:15:37 ]: >>851
そうなのか。Sunってなんか変なところでマーケティングが変なこと言い出す気がする。

1.1→1.2→1.3→1.4→5.0→6.0
なバージョニングといい

J2SE→Java SE
といい。
857 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 09:42:56 ]: いや、たんに世の中のバージョンとあわせただけだよ
sunの文化として0.1がメジャーバージョンアップなんだよ
でもマイナーバージョンアップにしか見えない

だから製品名と内部バージョンとをわけるという他の会社と同じものにあわせた
あと6.0はない、6だ
Java2登場前はただのJavaがあったし、SDKはJDKという名前でまたJDKに戻った

Java2という名前を入れるときに製品名としては2.0にすべきだったのさ

ただそれだけのこと
858 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 11:14:04 ]: マーケティング周りで散々分かり辛かったから一般消費者向けに分かりやすい製品名にしただけ。
ブランド名はずっとJavaの4文字だし。

JDKに戻ったのもsun内部ではずっとJDKと呼ばれ続け、開発者側もJDKで十分慣れ親しんだため。

そして何より、今はゲイツの相手せずに済むから・・・

J/Directなんて禁句だぜ？

アゝ、なつかしの*7・・・
859 名前：デフォルトの名無しさん [2007/04/28(土) 16:05:42 ]: ♪ア・ソ～レ

ア・チョン！ア・チョン！

ア・チョン！チョン！チョン！バカ！
860 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:11:38 ]: XMLリテラルよりヒアドキュメントに対応して欲しいのは俺だけ？

String sql = <<END_OF_SQL
update USER_TBL
set name = ?,
age = ?
where id = ?
END_OF_SQL
861 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:14:26 ]: IDE使っていれば改行を気にすることないから俺は要らんな
862 名前：デフォルトの名無しさん [2007/04/29(日) 00:34:43 ]: 複素数なんていらないじゃん。
commonsにライブラリあるからそれで十分。
863 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 08:52:50 ]: >>860
ヒアドキュメントは確かに欲しい
あと、ヒアドキュメント中にJavaの式を埋め込むこともできたらいいな
864 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 09:17:28 ]: 言語でサポートされるなら複素数型は欲しいな・・
865 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 09:57:06 ]: そういえばCSV(TSV, etc.)を読み書きするためのライブラリが標準でないのが気になった
866 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 10:20:46 ]: TSVやCSVは環境依存しまくりだからな
ほとんどの場合Excel準拠でいいのだろうが
H2のライブラリを使うという手もある

だが、まずはファイルのコピー等を実装するのが先じゃね？
867 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 10:47:04 ]: 仕様通りのCSVって見た事ないんだが。
カンマで区切る以外はメチャクチャだろ。
868 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 11:05:13 ]: >>867 仕様ってrfc4180？
869 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 11:53:46 ]: >>868 4180って後付けだし他のシステムで吐き出したCSVを扱う
ときには全く意味ないよね。
870 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 12:37:17 ]: 後付の規格にあわせていたら過去のソフトとの互換性が取れんからな
どうせやるなら文字コードやどのソフトで出力したかなどメタ情報がほしいね

そのへんつっこんでいくとXMLになるから意味がないのだけれども
871 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 12:55:08 ]: 後付規格以外では、独自規格乱立してんだから互換性取るなんて無理。

RFC準拠の標準ライブラリとかならともかく、
自分とこの独自規格に合ったのが欲しいなら
自前の CSVライブラリ作った方が楽だし簡単。
872 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:07:50 ]: ttp://opencsv.sourceforge.net/
これ使ってる。別に困った事はない。というか、ＣＳＶ使うのは止めて欲しい。
問題が解決するわけじゃないが、タブ区切りの方が好み。
カンマより、タブの方が文章中で出てくる頻度が少ない。

というか、明確に項目を区切るための制御文字があってそれを入力できる方がいいなぁ
873 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:08:18 ]: ちょうどCSVってかテキストデータのライブラリ作ってる。
MIMEにあるかIANAに見に行って、RFCも日本語訳参考にしてるから
たぶん仕様的には正確だと思う。

RFC4180についてだけど、セル内改行を LF にすればExcel CSVに対応できる。
しかしAccess CSVは CRLF で、RFC4180と仕様が同じという困ったちゃん。
読み込みは柔軟に、書き出しは目的に合わせて厳密にという対応が必要だね。
874 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:28:53 ]: 後付けでもECMA-262とW3C DOMはうまい事まとめてるのにね。
相変わらずMSはオープン標準に従う気はないし。

テキストフォーマットの読み書きといえばODFなんかの文書フォーマット読み書きライブラリが標準拡張くらいであっても良いのにね。
やるとしたらテキストコンポーネントのプラグイン扱いかな。
変なところで妙に充実してるのがjavaのクラスライブラリなんだし。
875 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:29:04 ]: >>873
おれもそのAccessとの対応を対数ヶ月前やった
ダブルクォーテーションの中はあらゆる改行タイプをゆるせばいいだけだったっぽい
動きとしてはAccessのほうが納得しやすい
876 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:35:53 ]: >>874
javaってinterface作るのは好きだけど
SPIを作るのは嫌いって人が多すぎるんだよね。
MP3とかOGGとかSound APIにちょこっとしか準拠してないしｗ
877 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:54:41 ]: >>876
インターフェース作る＝自分でAPI定義
SPIの実装＝定義にあわせて作る

だからまったく別の話じゃね？
878 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 14:00:48 ]: このルールにあわせろっていうのは好きだが、
ルールに従うくらいなら俺仕様でって奴が多いってこと。
879 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 21:31:55 ]: >>878
うわ、激烈耳が痛てぇ。 orz
880 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 23:46:40 ]: >>878
それじゃMSがやってることと同じじゃんか。
881 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 00:08:54 ]: まぁ、大抵の奴はそう思うんじゃね？
882 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 00:36:26 ]: >>876
例えば標準のプラグインがヘボいので上書きしたい場合みたいに
他のプラグインと衝突する場合のガイドラインがなかったりするし。
いざ作ろうとすると、SPIまわりはドキュメントが不足してる。

他にも、Sun の標準プラグインに必要なインターフェイスだけしかないとか
java.net.URLStreamHandlerFactory はなんで SPIになってねーんだとか
SPI自体がテキトーに作られてる感が無きにしも非ず。
883 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 10:26:19 ]: C99では複素数もとっくにサポートされてるのにJavaはダメだね。
コンパイラに実装するのは難しくないだろ。
いろんなComplexクラスとか見ると、また車輪の最発明なのかと思って悲しくなる。
884 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 10:55:57 ]: ここは・・・

C99なんて仕様だけだろﾌﾟｷﾞｬｰm9

って言えばいいのか？

マジレスもしとくか、複素数を普通の演算子で扱いたいって事なんだろうけど
Javaの流れとしてはXMLリテラルの方が先じゃない？
俺としてはどっちも要らんが。
885 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 11:42:39 ]: >>883
確かに人それぞれの複素数クラスがあるよね。
886 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 12:50:02 ]: 複数のライブラリを横断的に使ってて、
複素数型がライブラリ毎に違うのが面倒くさいとか
そーゆーケースでもない限り標準APIに拘る必要も無いような。

複素数型入れても今更感が強いし、
下手すると独自規格乱立したCSVに後付標準規格(?)ができたのと同じで
それほど意味がないものになるような気もする。
887 名前：デフォルトの名無しさん [2007/04/30(月) 12:55:54 ]: >>884
gccのC99じゃだめなのか？
Javaも無料のコンパイラ使ってるくせに…
888 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 15:30:34 ]: そんなにCがいいならC使ってればいいんでは？
889 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 15:56:36 ]: >>883
Complexクラスが標準になればいいだけの話か。
890 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 16:45:23 ]: 複素数リテラルのまえに、BigIntegerリテラルだろ。
891 名前：デフォルトの名無しさん [2007/04/30(月) 17:05:27 ]: Wikipediaをwikiって略すな！
同時にWikipedia以外のWikiも盛り上げよう！
892 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:17:46 ]: >>891
携帯するものなんて電話以外にもいくらでもあるのに
携帯電話を携帯って略すのもやめよう
893 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:29:32 ]: >>890
リテラルは知らんけど、BigInteger BigDecimal の演算子オーバーロードは
dolphin で追加されそうな気配はある。>>132 のスライドに入ってるし。

もっとも、目玉は closure と erase erasure だろうけど。
closure というか、function type の実装には
java.lang.function パッケージに引数型+戻り値型を名前にした interface を使うみたいだけど
（ {int=>int} なら java.lang.function.II みたいな名前で int invoke(int) だけを持つ interface）
これ、実行時に生成するなら同じ仕組みで List<String> とかも生成するんじゃないかな。
と妄想中。VM（厳密には ClassLoader？）に手を入れる事になるけど。

で、そっちに時間取られると演算子オーバーロードとかは漏れる可能性もあるもしんない。
894 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:57:08 ]: >>891
seasarスレにカエレ(・∀・)

ま、どうせこのスレとあっちのスレ、中の人は同じだがな。
895 名前：デフォルトの名無しさん [2007/04/30(月) 18:23:11 ]: MVMは次に乗らないのか？
スレッドはネイティブ対応しないのか？
あーらんに負けるぞ。
896 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 18:28:56 ]: > スレッドはネイティブ対応しないのか？
？？？
897 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:25:00 ]: いまだにグリーンスレッドと勘違いしてるんだろう.
898 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:34:54 ]: 一瞬Rubyスレかと思ったわい。
899 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:46:22 ]: >>898
ﾉｼおれもれも。
ところでRuby処理系のネイティヴスレッド化って完了したの？

YARV Ruby でぐぐってみたけど、ささだ先生のところは0.4.1くらいで更新が
止まってるみたいで、最新の状況がよくわからん。

あ、スレちがいか。すまん。
900 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:17:55 ]: >>893
目玉はBigIntegerとBigDecimalだと思うよ
業務アプリだとこの辺頻繁に使うし
901 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:19:27 ]: >>899
そういうときはJRubyに関連付けするのだ
0.9.9がでたのでもうすぐ正式版が登場
つまりJavaVM上でRubyは動かすのが正解

VM起動時間なんてJavaSE6なら2回目以降は0.5秒だから問題ないし
902 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:46:47 ]: >>900
っても、closureの話は聞こえてくるけどBigDecimalの話はあんまし聞こえてこないんだよね。
903 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:53:57 ]: >>902
仕事に絡まないプログラムならそうかもしれんが
仕事では使わないという場面はほとんどないからなぁ。
そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。
目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。
904 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:24:54 ]: >>903
いや、Sunがどーゆー実装にするとか、JCPでどーゆー提案が出たとか
そーゆー話が聞こえてこないって事なんだけど。
905 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:37:14 ]: JCPとかリードスペックとか現時的に業務に絡んでないやつらが多すぎなんじゃ？
906 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:42:30 ]: >そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。
>目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。
技術者として終わってるな
907 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:51:54 ]: >>906
じゃぁ始まってるアンタが変えてよ
908 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:56:07 ]: >>905
愚痴たれるんならマ板に行ってやれ。
909 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 22:04:35 ]: >>906
たとえ真実でも、言ってはいけない事ってのがあってだな……
910 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 22:28:02 ]: >>906-909

PGが絶対口にしてはいけない一言
pc11.2ch.net/test/read.cgi/tech/1176001986/l50
911 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 01:55:23 ]: >>889
ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
よりも、プリミティブな複素数型を言語に追加してくれってこと。

複素数は機種依存するもんじゃないし、
たとえばFFTや平面座標上の点の計算に活躍する。
912 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 02:00:43 ]: 小数点演算すらソフトウェア実装なのに面倒なことさせるな。
913 名前：デフォルトの名無しさん [2007/05/01(火) 07:17:37 ]: > 現時的に業務に絡んでないやつらが多すぎなんじゃ？

現実的に国内で業務システムに絡んでる奴は
頭弱すぎて割り込めないだけ。
914 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 07:49:23 ]: >>911
> たとえばFFTや平面座標上の点の計算に活躍する。
の用途のために、何故
> プリミティブな複素数型を言語に追加してくれってこと。
が必要なのかわからん。クラスじゃ何でダメなんだ？

あと「プリミティブな」ってVM変更（バイトコードインストラクションを拡張）しろって話？
たぶん、そんな要求してもマトモに相手にされないと思うけど。
915 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:19:29 ]: この人は、単に複素数リテラルと演算子のオーバロードが欲しいだけだと思う。
言葉が不自由なので、自分の要求を正しく伝えられないのでは？
916 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:35:19 ]: >VM変更（バイトコードインストラクションを拡張）しろって話？

言語仕様の追加みたいだけど、どこからVM仕様追加の話になるんだ？
C99のようにゴニョゴニョっとまねして、チャチャッ実装しちゃってくれってことじゃないのか。
まあ、あれば便利だし、有難く使わせてもらうけど。
917 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:42:26 ]: 自分で実装してJCPに提案しろｗ
918 名前：デフォルトの名無しさん [2007/05/01(火) 08:54:09 ]: 演算子をオーバーロードして、BigDecimalの割り算はどうやって丸め指定を表現するんだろ
919 名前：デフォルトの名無しさん [2007/05/01(火) 08:56:26 ]: Javaの複素数演算用クラスって、どっかになかったか？
いちいち、引数をとらないといけないし、Fortranなどマシン語レベルの
ライブラリ充実している言語と比べると、スピードが出ないだろうけど、
だからといって、VM仕様から変更は影響が大きすぎるだろ。
920 名前：デフォルトの名無しさん [2007/05/01(火) 09:06:24 ]: >VM仕様から変更

だからどうしてVM仕様変更の話になるんだと小一時間（ｒｙ
921 名前：デフォルトの名無しさん [2007/05/01(火) 09:14:02 ]: >>920
java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19511
922 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 09:36:30 ]: >>912
strictfpで宣言しない限り結局はFPUに計算させてない？
923 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 10:37:21 ]: >>916

>>911 の
> ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
> よりも、プリミティブな複素数型を言語に追加してくれってこと。
から。

クラスもダメで、演算子オーバーロードもダメで（たぶんリテラルもダメ）、
プリミティブな型を追加と言われたらバイトコード拡張なのか？ってのは至極当然。
924 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 11:13:54 ]: 意味なしリクエストは却下
925 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 04:33:33 ]: >>916
>>921
>>923
それがどうやって実装されるかということを君達がアレコレ妄想する必要はない。
それがあればどう世界が変わるかだけを考えろ！
926 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 07:43:02 ]: まったく変わらない。
以上
927 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 08:46:01 ]: >>915
複素数リテラルって何？
3.1i
1 + 2i
"3 + 4i"
とかのことか

それと演算子オーバーロードは、
Complex,Matrixクラスの話題とよくセットで出てくるが、
その程度で演算子オーバーロードを実装するのはコストが
高いなどの論点とは今回は関係ないようだ。

おまえは思い込みが激しいようだな。
928 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 08:57:25 ]: 言語不明瞭意図不明。
929 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 09:03:14 ]: >>927
>>928
おまえ誰だよ。早く消えちまいな。
930 名前：デフォルトの名無しさん [2007/05/02(水) 09:35:38 ]: 野次と荒らしは2chの花
931 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:39:25 ]: >>930
ｦﾀとDQNが抜けてるぞ
932 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 06:00:15 ]: >>925
どう実装されるかはしらんが、プリミティブ型を追加するという時点でVMに手をいれないといけないのは決定だろ。
933 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:20:31 ]: C99だと
struct complex {double real, imag;}
struct complex {double z[2];}
とかで実装されてるんじゃないか。
だからコンパイラの拡張のみでマシーン（VM)の方に手を入れることはない。
というか、一般人が実装のことを考える事自体が意味ないじゃん。
934 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:32:36 ]: 配列で大量に計算する用途だとクラスよりC#の値型のようなものがあるとベターだな。
935 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:58:40 ]: >>933
えーと。
結局、プリミティブな複素数型は特に必要がなくてクラスでやってもOKって話かな？

本当に複素数型欲しいなら
現時点でGPLで配布されてる javac に複素数型導入して公開したり、
そのパッチを ksl に投稿してみるとか、
BugDatabaseに行って、RFE出すとか既存のRFEに投票するとか、
その bugID 晒して、皆に投票呼びかけたりとか、
もちっと前向きな行動した方が良いと思うよ。

ここで複素数追加みたいなネタ振られたって、
皆でどーゆー実装するのか妄想して遊ぶぐらいしかできないでしょ。
936 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:09:09 ]: 座標上の点の計算には便利そうだ。特に回転とか。
複素数クラスがあってもnewしまくるから遠慮してたけど、
言語に追加されるなら便利そうだけどな。

今のトレンドは言語に複素数を追加することなんじゃないか。
C,D,Pythonは既に言語レベルでサポートしてるし。
937 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:25:59 ]: トレンドってほど支持する流れも否定する流れも大きくないと思うが……
938 名前：デフォルトの名無しさん [2007/05/03(木) 10:37:45 ]: >>933
頭悪そう
C99を使ってろ
939 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:53:07 ]: >>936
ちなみに、何を作りたくて複素数型が必要なんだ？
940 名前：デフォルトの名無しさん [2007/05/03(木) 10:57:23 ]: >>934
C#の値型は、クラスと比べてどんなメリットがあるの？
コンパイル時に最適化されて
ランタイム負荷が小さいとか？
941 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:34:41 ]: >>940
クラスのオブジェクトに比べ生成と削除のコストが低い。
値型は参照を介せずにスタックに直接値が格納されたり、
配列やクラスのメンバーとして直接その領域に値が格納されるので
ボクシングが発生しない限りGCの必要な実体が作られることがない。
このためプリミティブ型に近いパフォーマンスを発揮する。
942 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:45:20 ]: >>939
必要ないんでしょ。

ってか、実際に複素数型が必要な分野のプログラム組んでる人間が
「演算子オーバーロードよりもプリミティブな複素数型」なんて言うとは考えられないし。
943 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:50:30 ]: >>941
値型ってのが広い範囲を表すからいいたいことがあいまいだぞ
944 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 15:00:41 ]: 下手に構造体チックなものが登場されてもBeanの文化が壊れるから
ByteBufferで我慢が出来ないなら諦めてくれって方針で十分。
945 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 19:32:28 ]: >>933
だから、それはプリミティブ型じゃないだろ。
946 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 20:49:44 ]: Ｃ＃の値型みたいなのがほすぃ
って言いたかっただけなんじゃないか、と。
947 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 21:32:14 ]: >>946
Java に C# の値型みたいなの導入すると
コンパイラ弄るだけじゃすまなくて、それこそ VMの変更が必要なりそうだし。
メソッドの戻り値で値型を使う場合とか。

それに、C# は最初から値型があったから良いけど、
Java の場合は generics 導入しちゃった後だからねぇ。
今から C# の値型みたいなものを追加したとしても
現時点でのプリミティブ型みたいに generics で使えなさそうだし。
948 名前：デフォルトの名無しさん [2007/05/03(木) 21:52:46 ]: Javaも遅かれ早かれVMの拡張は必要になると思うのだがいつごろ来ると思う？
949 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:05:05 ]: >>948
おいおい……
バイトコードインストラクションの話ならJSR-292のinvokedynamic追加の検討中。
後は>>893がfunction type関連でVM拡張とか言ってる。
950 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:13:31 ]: >>949
さんくす。複素数の議論でVM拡張は避けるべき的な話が出てたので確認してみた。
別にVM拡張前提で話をしてもかまわないわけだよね。
951 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:21:32 ]: >>950
ここは「次世代Javaの動向」をヲチるスレだから、
新機能追加の要望とか、単なる妄想オナニーなら他所でやってくれ。
952 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:24:40 ]: だれもVM拡張は避けろといってなくて、プリミティブ型を追加するならVM変更という話と、そんな無意味な要求は却下されるよという話が同時進行してただけかと。
953 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:28:41 ]: >>951
ヲチするだけとはどこにも書いてないわけで。
しかも、最初から要望とか妄想オナニーばかりのスレで、950も過ぎてから言ったところで説得力ない。
954 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:32:05 ]: >>953
今回ので言えば、既に >>935 で他所行けって出てるし。
他の話題でも他所行けってのは散々出てるし。
955 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:38:34 ]: つまり、スレの流れについていけなくてわめいてるってわけか。
956 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:41:32 ]: >>953
便所に落書きしても要望だとは思われないよな。普通は。
957 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 01:17:58 ]: 複素数を扱うライブラリがあれば便利だと思うが
言語仕様に含めるのはやり過ぎです。

ところで値型って、VBのByValを指しているの？
958 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 01:45:44 ]: >>957
ここは予想や感想を述べる場所じゃないとのことなので、
そういう動向は今のところ無いということでおしまいらしい。

値型はVB.NET以降では、ユーザー定義型（Structure）、Enum、クラスを除くVBの基本データ型をさす。
VBのデータ型と.NET(CLR)のプリミティブ型は若干違うから注意。
ここではユーザー定義型（Structure）の意味で使ってる。
.NET(CLR)ではValueType C#ではstruct。
Javaだと参照型以外の型＝プリミティブ型＝値型という理解でいいのかな？（自信は無いが）

あとは質問か雑談スレへとかいわれそうだ。
959 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 03:50:43 ]: >>956
「普通は。」ってなんだよ 9m(^x^
960 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 09:51:42 ]: C#：全部ヒープに置いたら遅いだろ！struct導入する！
Java：エスケープ分析で自動的にスタックに置くｳﾏｰ
961 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 12:14:58 ]: どうもsturct(値型）の話になってるようだけど、なんなら
typedef double complex[2];
でいいじゃん。どう実装されるかなんかはベンダ任せなんだけどね。
962 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 19:07:54 ]: ベンダ任せなわけがない
963 名前：デフォルトの名無しさん [2007/05/04(金) 20:59:25 ]: Hさん、居るよね。
964 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 21:03:27 ]: MさんとKさんもいるよね。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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