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

[mustang/Java SE 6] ..

562:デフォルトの名無しさん
07/03/03 11:21:52
>>558はgetClassしてる時点でどうなるかをかんがえればよろし

563:デフォルトの名無しさん
07/03/03 14:24:41
>>553
初心者質問スレ行けよ。

564:デフォルトの名無しさん
07/03/03 15:28:47
>>556-563
㌧

565:デフォルトの名無しさん
07/03/04 09:29:05
>>551
追記：
見た目で大きく変わるところ発見。
Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！
可愛いです。

デュークのライセンス変更で、こういう事になったのね
わかりにくいカップよりコレはいいな

566:デフォルトの名無しさん
07/03/05 16:02:11
invokedynamic 使えるかどうかプログラム側から判断するのって、どうすれば良いですか？

567:デフォルトの名無しさん
07/03/05 16:44:34
>>566
実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、
エラー出たら使えないんじゃね？

そーいや、invokedynamic って今どーなってんだろ？
invokedynamic のオペランドとかの詳細あったっけか？

568:デフォルトの名無しさん
07/03/11 15:34:36
某スレの 288 へレス。
> クロージャよりは揉めずに入りそうな気がしてる。
ウソはいかん。javac の人なんかはイラネって言ってるし。

URLﾘﾝｸ(blogs.sun.com)
要は、プロパティに dot でアクセスしようとすると、
既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。
例えばフィールド宣言したコンパイル単位ではフィールドアクセスでそれ以外ではプロパティアクセスとか、
プロパティと同名のフィールド持てないとか、そんな感じのルール。
どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。
もしくは "->" とかでプロパティにアクセスするとかだけど、これはこれでキモイから嫌なんだそうで。

URLﾘﾝｸ(weblogs.java.net)
ksl でプロパティの試験実装してた人とかも、
Access to property は setter getter で、って意見変えてるし。

569:デフォルトの名無しさん
07/03/11 17:20:57
>>568
そうか、キモイか・・・うん、キモイなぁ

dotを使うのは、駄目と言う点は全く賛成だが
表記方法さえ、決まればOKだと思ってるんだけどなぁ

俺は、個人的な好みは->はキモイけど、 : ならOKです。

570:デフォルトの名無しさん
07/03/11 17:41:54
::
.
.*
->
->*

いろんな言語のaccessor。あと何があったっけ？

571:デフォルトの名無しさん
07/03/11 17:48:11
>>569
オレ自身は "->" でもいいじゃん、とか思ってたりする。
他の人が "->" がキモイって言うのも理解できるんだけど。

URLﾘﾝｸ(jroller.com)
${classInstance.propertyName} みたいに ${} で括った部分では
式言語使えるようにすりゃええやん、ってのも出てるけど……
そこまでして dot に拘らんでも、と思わなくもない。

572:デフォルトの名無しさん
07/03/11 18:14:36
>>569
:: じゃなくて : なの？

class A { property Object b; }
class B { property Object c; }
class Hoge {
　A a; B b; Object c;
　boolean flag;
　Object method(){
　　return flag ? a : b : c;
　}
}
とかされると分かりにくくなるよーな気もする。
構文解析自体は結合順位とかがあるから出来ると思うけど。

573:デフォルトの名無しさん
07/03/11 18:15:17
dot人気ないね。
フィールドアクセスとプロパティのインターフェースを別のものにしたら、
単なるgetter/setterの省略表記になってしまってあまりうまみがないと
思うのは俺だけかな？

574:デフォルトの名無しさん
07/03/11 18:42:44
>>573
皆が納得できる上手いルールが作れれば dot でも良いと思うけど。
人気がないって言うよりも、>>568 のような追加ルールを決める部分を
誰もやりたがらないような気もする。
簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、
なるべく互換性維持しようとすると、ルールが複雑になって
今度はコンパイラの作者とかから嫌われるだろうし。

>>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の
blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、
もしくは問題自体を理解してないような。

C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、
Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから
getter/setter の省略表記と割り切った方が現実的じゃないかな？

575:デフォルトの名無しさん
07/03/11 22:38:47
>>572
あ、いや、: ←コロンを使うという意味だった。
Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。
一つだと、 hogehoge==null？a : b;
とか、switchが混乱するから。

>>573
いや、むしろそれがいい。
見たら裏で何をしているかがよく分かる。
別に、dotではなくて :: でも可読性は落ちないと思う。

-> は、演算記号と紛らわしくて、嫌。

576:デフォルトの名無しさん
07/03/11 23:03:00
プロパティなんてそもそも本質的には冗長な機能なんだから、
どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。

577:デフォルトの名無しさん
07/03/11 23:08:52
> マイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
具体的には？

578:デフォルトの名無しさん
07/03/12 03:22:06
C++で->使ってるから、->でいいや。

579:デフォルトの名無しさん
07/03/12 04:10:14
>>576
VBだとdotじゃなかったっけ？

580:デフォルトの名無しさん
07/03/12 08:32:28
>>577,579
VB,C#ともどっとだね。
仕様策定してる連中がドットを嫌う理由がよくわかんない。
どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
新しくプロパティの意味を持たせても別にいいと思うんだが。

581:デフォルトの名無しさん
07/03/12 08:50:48
>>580
C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？
まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。
Javaに、そんなルール後付けしたら互換性無くなるし。

なんでこんな簡単な事が理解できないのかわかんない。

582:デフォルトの名無しさん
07/03/12 08:55:00
>>581
プロパティ自体後付けじゃん…て思ったんだけど、
setter/getterペアにアクセスする演算子のことなのか。
プロパティ定義の構文も新しく作るのかと思ったよ。
C#の Property Hoge { ～ } みたいにさ。
だったら「そんなもんｲﾗﾈ」に一票だなあ

583:デフォルトの名無しさん
07/03/12 09:19:05
>>582
> プロパティ自体後付けじゃん…て思ったんだけど、
JavaBeans のプロパティ自体はあって、その構文糖を追加しなければならない。
だから、完全に後付けってわけでもない。
JavaBeansのプロパティや、それを使ってる既存のフレームワーク捨てるなら別だけど。

あとプロパティ定義の構文を新しく作っても、プロパティアクセスに dot 使えば問題は出る。
例えば、
class MyComponent implements java.beans.DesignMode {
　private boolean designTime;
　public boolean isDesignTime(){ return designTime; }
　public void setDesignTime(boolean f){ designTime = f; }
}
みたいな既存のコードがあるとする。

プロパティが追加されて java.beans.DesignMode が
interface DesignMode {
　public static final String PROPERTYNAME = "designTime";
　public abstract property designTime;
}
みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。

584:デフォルトの名無しさん
07/03/12 09:57:09
>>580
> 仕様策定してる連中がドットを嫌う理由がよくわかんない。
dot 使ったらフィールドアクセスとプロパティアクセスの区別がつかなくなると何度言えば……

585:デフォルトの名無しさん
07/03/12 10:02:47
>>580
> どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
ひょっとして、現存するソースコードに Beans のプロパティ持ってるものが
大量にあるって事がわかってない？

586:デフォルトの名無しさん
07/03/12 11:37:56
だからさ、プロパティってのはgetter/setterペアのことじゃなくて
それとは別に新しい概念を持ち込むのかと思ってたって>>582に書いたでしょう。
何嬉しそうにツッコミいれてんだよ。

587:デフォルトの名無しさん
07/03/12 11:41:08
> 何嬉しそうにツッコミいれてんだよ。
いや、無知だなぁ、と思って。

588:デフォルトの名無しさん
07/03/12 11:51:08
>>587
どの辺が無知だったか教えてちょ。勉強するから。

589:デフォルトの名無しさん
07/03/12 11:56:57
>>588
このスレに出てるのだけでも、プロパティに関するリンク先読んでれば
beans と関係のない新しいプロパティを導入するとか思わんでしょ。普通。

590:デフォルトの名無しさん
07/03/12 13:21:21
>>589
そうだな。すまんかった。

591:デフォルトの名無しさん
07/03/12 20:35:44
>>583
>みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。

ここがよくわかんないんだけど、誰か解説して。
アクセッサがあればそちらを優先的に使う（あるいは逆にフィールドアクセスを優先する）というルールを決めればすむ話じゃないの？
で、583みたいな状況になったらコンパイラが警告を出してくれればそれでいいと思うんだけど。

592:デフォルトの名無しさん
07/03/12 20:47:38
>>591
> アクセッサがあればそちらを優先的に使う
それやったらコンパイルが通らん。

> フィールドアクセスを優先する
フィールドでプロパティを上書きできるようになるけど、それで良いんか？

593:デフォルトの名無しさん
07/03/12 20:56:24
× フィールドでプロパティを上書き
○ フィールドでプロパティを覆い隠し

594:デフォルトの名無しさん
07/03/12 21:00:25
>>592
> > アクセッサがあればそちらを優先的に使う
> それやったらコンパイルが通らん。
いや、コンパイルは通るかもしれんが……

例えば
> public boolean isDesignTime(){ return designTime; }
は public boolean isDesignTime(){ return isDesignTime(); }
に展開されるから実行時に StackOverflowError 吐いて死ぬ。

595:デフォルトの名無しさん
07/03/12 21:20:38
>>584
区別させないのがプロパティだろうに。

596:デフォルトの名無しさん
07/03/12 21:24:32
>>595
コンパイラが区別できないって意味なんだけど。

人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。

597:デフォルトの名無しさん
07/03/12 22:11:17
>>596
まぁ互換性を維持してのプロパティの導入には実装上の困難を
解決できていないというのはいいんだが、だからといって
「できる方法で実装しちゃおう」となるとしたら賛成できないなぁ。

互換性の面から考えた場合、方法は大きく3種類に分類できて、

1.JavaBeansと相互に互換性のある方法
2.JavaBeansとは互換性がないが、バイトコードレベルでの
　仕様変更を伴わない方法
3.バイトコードレベルで拡張する方法

このうち、3.を採用すると何でもありだから議論から除外するとして、
個人的には1.には拘らないから2.でうまいことやってくれないかなと
思うんだが。

598:デフォルトの名無しさん
07/03/12 23:05:53
>>597
1 の場合はともかく、2 や 3 の場合はコンパイラ実装するとか言語仕様追加する、
とかってのは一番楽な部分だからね。

JavaBeans を切り捨てるってのは、技術的というより政治的な問題だから、
ハッカー気質が強い人ほど、自分でコード書いたりする時間がなくなって
政治的な問題に時間を取られる、って予感があるので手を引きたがる。

2 の場合は機能を欲しがる人は居るかもしれんけど、
（2 をやれるだけの政治的立場とか確保してる人の中で）
やりたがる人は居ないと俺は思うから、たぶん実現できないと思う。

599:デフォルトの名無しさん
07/03/12 23:18:49
> JavaBeans を切り捨てるってのは
切り捨てるわけじゃないか……

でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
標準API とかの setter/getter を新プロパティで置き換えるとかってなれば
厄介な政治的問題だってのは予想できるでしょ。

言語として 2 のプロパティ持ってても、
標準API は 2 のプロパティをサポートしませんとかなったら間抜けだし。

600:デフォルトの名無しさん
07/03/12 23:26:45
> でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
こんな決定したら袋叩きにあうような気もする。
メンテ面倒くさいし。

enum でも、似たような事やってたけどさ。
enum だと、自前の enum を定義するクラスが比較的少ないから
メンテが面倒って不満がそれほど大きくならんかっただけだと思うし。

601:デフォルトの名無しさん
07/03/12 23:30:42
XMLEncoderがenumに対応してないと気づいたときに、Javaは終わったと思った。

602:デフォルトの名無しさん
07/03/12 23:34:54
これ?
URLﾘﾝｸ(bugs.sun.com)

603:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/13 09:38:13
>>603
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
> これなら大丈夫じゃない？
package-private もしくは protected なフィールドと、
public なプロパティで問題起こるから解決になってない。

606:デフォルトの名無しさん
07/03/13 10:13:00
>>604
> 覆い隠しって単純名だけに作用するんじゃないんかな？
違うか。覆い隠しじゃなくて、隠蔽されたフィールドは継承されないから、
B のインスタンスからは A の field にはアクセスできないのか。

名前の章ばっかし見てたら理解できんかった。

607:デフォルトの名無しさん
07/03/13 10:17:35
どっちにしろ、今更プロパティを言語仕様に導入しようなんて考えるのが間違ってる。

608:デフォルトの名無しさん
07/03/13 12:25:26
間違い、とまでは思わないけどね。

609:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/13 15:00:26
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
(this).bar とかだとどうすんだろ？

611:デフォルトの名無しさん
07/03/13 16:53:37
ってか、そーゆールールなら
・フィールドが可視ならフィールドアクセス
・そうでなければ、プロパティがあるならプロパティアクセス
とかの方が良いような気もする。

それでも static なプロパティを許したりすると、同名のメンバークラスと衝突するし。
ってか、同名のフィールドが可視なら shorthand syntax for accessing properties
を使えないのって、本当に使いやすいかも結構問題のような？

612:デフォルトの名無しさん
07/03/13 19:42:20
何か激しく壊れてない？
URLﾘﾝｸ(download.java.net)

613:デフォルトの名無しさん
07/03/13 19:42:27
>>604
>違う
というのは勘違いということでいいのかな？

>そうだよ。だから無理だって言ってるじゃん。
だから『展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく』といっているんだけど。

>そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。

614:デフォルトの名無しさん
07/03/13 19:48:30
>>613
＞なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
汚い設計。
わかりにくいです。
あとマルチスレッド周りで問題がでそうだな。

615:デフォルトの名無しさん
07/03/13 20:05:41
>>613
> というのは勘違いということでいいのかな？
いや、覆い隠しは勘違いだったけど、
private フィールドで public なプロパティを隠蔽できるから問題になるのは変わらない。

> 区別してないなら区別すればいいじゃん。
区別しても、 >>605、>>609、>>610 みたいな穴があるから、やるだけ無駄。

616:デフォルトの名無しさん
07/03/13 20:44:57
>>611
どっちかっつーと dot でプロパティアクセス許す場合、
フィールドと同名のプロパティを作れるってのが混乱の元だとか認識されてんのかも？

617:デフォルトの名無しさん
07/03/13 20:51:03
> あとマルチスレッド周りで問題がでそうだな。
問題でるかな？

618:デフォルトの名無しさん
07/03/13 20:53:23
>>613
> なんで無茶なの？
根本に近い方のルールを書き直すってのは、
既存のコンパイラを改変する時に多くの労力がかかりそうだってのは分かるでしょ？

だから無茶なの。

619:デフォルトの名無しさん
07/03/13 21:20:36
>>571
> ${classInstance.propertyName} みたいに ${} で括った部分では
> 式言語使えるようにすりゃええやん、ってのも出てるけど……

ksl の課題追跡にあった
URLﾘﾝｸ(ksl.dev.java.net)
に似てるっちゃ似てるかも。

でも、ecmascript みたいに Java と同じく } でブロック終了する言語だと
対応とるの大変そうだなとか思った。その辺は EL だと楽だけど。

620:デフォルトの名無しさん
07/03/13 21:34:43
ヒアドキュメント＋式言語ってのが良さそう
Velocityが標準になるみたいな感じだが。

621:デフォルトの名無しさん
07/03/13 22:29:53
>>616
要は、今の仕様で

private int xxx;

というフィールドと

public int getXxx()

というメソッドが混在できる以上、フィールドの延長上のプロパティと
getter/setterの延長上のプロパティとは相容れないわけだ。

いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
関係もないことにすりゃ、それで解決すると思うんだけどね。

622:デフォルトの名無しさん
07/03/13 22:49:49
>>621
> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決すると思うんだけどね。

仮に、それをやっても「解決する」のは言語仕様の問題だけで、
ライブラリ＆フレームワーク＆ユーザーコードの方に問題を押し付けてるのような。
それなら、ぶっちゃけ新しい言語作っちゃった方が速いと思う。

623:デフォルトの名無しさん
07/03/13 23:18:12
>>622
上の方でだれか言ってたけど、フレームワークのプロパティとは無関係な「Java言語プロパティ」
を作ってもいいんじゃないか。紛らわしいなら名前は変えてもいいけど。
そもそもなんでプロパティ構文が欲しいんだ。ドットネットが羨ましいんだろうか。

624:デフォルトの名無しさん
07/03/13 23:24:53
>>622
「問題」って、どんな問題かな？
別に既存コードの変更が迫られるわけじゃないっしょ？

625:デフォルトの名無しさん
07/03/14 00:09:08
>>623
むしろstructが羨ましいんじゃないか？

626:デフォルトの名無しさん
07/03/14 02:48:40
>>624
互換性を確保しつつ新プロパティを使おうと思ったら、
既存のプロパティと、新プロパティの両方管理しなきゃいけなくなる。
二重のコストを払う必要が出るんだから、普通は問題になる。

おまけに、フレームワークやライブラリが二重のコストに耐えかねて
既存のプロパティを捨てたら、やっぱり既存のコードを書き換える必要が出る。
直接コードの変更を迫ってないだけで、間接的にコードの変更を迫ってる。

627:デフォルトの名無しさん
07/03/14 07:18:35
>>626
プロパティが導入されたからといって、既存のコードを無理に
対応させることはないでしょ？別物なんだから。

それに例えば、ジェネリクスが導入されたとき、それに対応して
書き換えられたフレームワークはあったし、もちろんそれを利用
しているユーザーコードも書き換えられることがあったけど、
それは別に変更を余儀なくされて行ったわけじゃないよね？

628:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/14 08:10:26
定義はgetter/setterで行って、呼び出すときだけプロパティみたいにも使えるようにするのじゃダメ？
例えば、p=a.getXxx()をp=a.xxx、a.setXxx(p)を a.xxx=pとか。

630:デフォルトの名無しさん
07/03/14 08:37:50
>>629
それだと dot でやるのが面倒。

既存の getter/setter に使われてる「プロパティの名前」と
同名のフィールドが存在可能だから。

631:デフォルトの名無しさん
07/03/14 08:39:25
>>628
そのコストってのもフレームワークの作者とかはともかく開発者は関係ないね

632:デフォルトの名無しさん
07/03/14 08:44:16
>>631
何より、無駄にバグのリスクが増えるし、
標準APIとかでドキュメントの翻訳に時間がかかるようになるとも考えられるね。

633:デフォルトの名無しさん
07/03/14 08:45:07
>>631
開発者というより、末端ユーザだな

634:デフォルトの名無しさん
07/03/14 09:10:34
>>629
a.xxx と同名のフィールド a.xxx があった場合、扱いが面倒。

互換性を考えるなら >>611 あたりのルールが落としどころかとも思うけど、
public な同名のフィールド使えば、プロパティに触れなくする事ができたりするし、
完璧とはいいがたい。

言語仕様に書く文言も相当慎重に選ばないと、
デフォルトパッケージのクラスが import 出来なくなったみたいに、
言語仕様の文言から副作用がでる可能性も……
もっとも、import の方は意図しない副作用なのか意図的なものか、
ちゃんと知らんのだけど。

635:デフォルトの名無しさん
07/03/14 12:24:27
マルチコア対応は言語に乗っかるのか、VMに乗っかるのか・・・

636:デフォルトの名無しさん
07/03/14 12:37:32
>>627
Genericsは、既存の一般コードに関しては意味の変更なく使えたぞ
>>632
さすがにそのコストを考えるのは臆病すぎｗｗｗ
>>635
マルチコア対応って一体何なのか分からない。

なぁ、何でみんなdotにこだわるの？
別の記号にして、定義も全く別にすればスッキリ導入なんだけど？
バイトコードは拡張しないと駄目だろうけど。

637:デフォルトの名無しさん
07/03/14 12:48:08
>>636
> 別の記号にして、
dot 以外の記号はキモイから嫌らしい。

> 定義も全く別にすれば
既存の資産と協調して使えないので、導入しても嬉しさ半減。

> バイトコードは拡張しないと駄目だろうけど。
バイトコード拡張は必要ないでしょ。
クラスファイル仕様は弄るかもしらんけど。

638:デフォルトの名無しさん
07/03/14 12:50:02
>>635
マルチCPU対応のVMだったら、マルチコアもそのまま使えるんじゃない？

ってか、マルチコア対応を言語にのっけるってどーやるんだ……

639:デフォルトの名無しさん
07/03/14 13:13:07
そういやRhinoのLiveConnectは実装側で拡張されててJavaObjectのゲッタ(getXxx)・セッタ(setXxx)にJavaScriptObjectのプロパティ(xxx)からアクセス出来たな。
JavaBeans使ってたんだろうか？

結局JavaScriptObjectのプロパティからアクセスしようとした時JavaObject側にxxxってフィールドがあると衝突して使い物にならないから
LiveConnectには元々ない後付けされた機能なんて不完全だって言われてたな・・・。

オライリーのサイ本にも指摘されてたような。

640:デフォルトの名無しさん
07/03/14 13:39:56
>>626
阿呆だな。もっと簡単な問題があるよ。

>>624
JavaBenas のプロパティと別のプロパティなわけでしょ？
標準API とかの既存の interface に abstract な property を追加したら
既存のコードの中で、そのinterface を実装してて JavaBeans とは別のプロパティを
実装してないクラスがあれば、互換性に問題が出る。
互換性に配慮したら interface に迂闊にプロパティ追加できない。

それだと、たぶん使い物にならない。

641:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/14 14:10:45
なるほどいろいろ問題があるな。
結局　->案が一番妥当だろう。
プロパティを定義する側はこれまでどおりgetXXX/setXXXを使用する。
プロパティを使用する側はgetXXX/setXXXと->XXXの両方が使える。
フィールドにXXXがあっても問題なし。
しかし、この程度のものならいらないな。

643:デフォルトの名無しさん
07/03/14 15:29:22
>>642
だよな。
いらないと思うよな。

644:デフォルトの名無しさん
07/03/14 15:41:27
あとはgetとsetを対にした定義文もほしいな

645:デフォルトの名無しさん
07/03/14 15:47:49
>>641
今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入するのだったらその書き換えはいらないよね？

646:デフォルトの名無しさん
07/03/14 16:03:21
>>645
だから、>>641 は
> 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入
した場合に発生する問題だってば。

今Beansで「プロパティ」と呼んでいるもの、
要するに setter/getter呼び出す syntax sugar として
accessing properties な構文を入れるなら、>>641 の問題は発生しない。

647:デフォルトの名無しさん
07/03/14 16:36:28
>>646
なんで書き換えようとするの？そのままにしとけばいいじゃん。

648:デフォルトの名無しさん
07/03/14 16:56:32
>>647
>>641 をちゃんと読め。

649:デフォルトの名無しさん
07/03/14 17:45:12
>>648
ちゃんと読んでもわからないです。
何故 interface DesignMode に property designTime を追加してるの？
ひょっとして俺ｽｹﾞｰアホなこと訊いてる？

650:デフォルトの名無しさん
07/03/14 18:38:36
> ひょっとして俺ｽｹﾞｰアホなこと訊いてる？
うん。

651:デフォルトの名無しさん
07/03/14 22:27:50
>>641
あきれる。
isXXX()/getXXX()をgetterのインターフェースに用いたままプロパティを
実現しようとすることに問題があるから別のインターフェースを採用
しようという話なんだから、その例でinterfaceの方にisDesignTime()を
追加するという仮定自体がそもそもありえないし、仮に追加しても
何の影響もない。

652:デフォルトの名無しさん
07/03/14 22:35:24
dot以外の記号がキモイならdot二つのx..hogeでもいいよ。

653:デフォルトの名無しさん
07/03/14 23:25:14
>>652
孔明あらわる

654:デフォルトの名無しさん
07/03/14 23:56:34
>>651
俺もそんな気がしたんだけど、>>650 だそうです。

655:デフォルトの名無しさん
07/03/14 23:57:20
記号でわざわざ入力二回って耐えられなくない？

656:デフォルトの名無しさん
07/03/15 00:00:24
耐えられないなら++も--も使わずにプログラムを書いてくれ。

657:デフォルトの名無しさん
07/03/15 00:45:46
// << >> == && ||
↑これらも

つか==なしとか縛りきつくね？

658:デフォルトの名無しさん
07/03/15 00:47:52
VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
FlashのActionScript(ECMAScript派生)もread onlyプロパティがあったが、dotだね。
dot以外を選択するのは、正直コンパイラ屋の都合でしかないと感じる。
メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。

659:デフォルトの名無しさん
07/03/15 01:30:43
ちょっと待てECMAScriptは全部プロパティだ

660:デフォルトの名無しさん
07/03/15 01:32:16
>>656-657
2chらしい模範解答だなｗ

661:デフォルトの名無しさん
07/03/15 01:52:21
IDEやJava用エディタならテンプレート機能が充実しているし
そんな構文糖は要らないってのも意見として尊重してほすぃ。

662:デフォルトの名無しさん
07/03/15 02:15:35
>>661
どうなんだろ、セマンティクスがハッキリするから
getter,setterが分かりやすくなるという点ではIDEも歓迎なのでは？
実現方法はともかく。

663:デフォルトの名無しさん
07/03/15 04:06:26
>>661
コードの読みやすさが上がるのであれば、新しい構文糖の導入も大いに結構じゃないかい？

664:デフォルトの名無しさん
07/03/15 07:43:28
>>651
あきれる。

> 仮に追加しても何の影響もない。
そんなは事ない。

665:デフォルトの名無しさん
07/03/15 07:47:20
>>651
>仮に追加しても何の影響もない。
追加したら、java.beans.DesignTime を実装している既存のクラスを書き換えなきゃいけなくなるだろう。

影響がないって、馬鹿じゃないのか？

666:デフォルトの名無しさん
07/03/15 07:48:08
>>665
× java.beans.DesignTime
○ java.beans.DesignMode

667:デフォルトの名無しさん
07/03/15 08:18:45
>>661
URLﾘﾝｸ(java.net) とか見ると、
property構文は、XML構文に次いで人気がないんだよね。

URLﾘﾝｸ(java.net) とかだと、
very important と、somewhat important をあわせても 1/4 ぐらいだったりする。

まぁ、この手の投票がちゃんと機能してるかはわからんし、
構文糖なら要らないってのと、重要度が低いってのは同じ意見じゃないんだけど。

668:デフォルトの名無しさん
07/03/15 08:34:05
>>658
> VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
もし問題がないなら dot を使うのに反対の人はあんまし居ないと思うんだが。
同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
わかりにくくないって言うんならともかく。

> メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。
それって、何か改善する？

669:デフォルトの名無しさん
07/03/15 09:09:07
>>668
> 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
> わかりにくくないって言うんならともかく。
それなら、同名のフィールドとプロパティが共存できて、
さらにフィールドもプロパティも dot でアクセスする言語がわかりにくくないって言わないと。
（dotじゃなくても良いけど同じ記号でアクセスする言語）

670:デフォルトの名無しさん
07/03/15 09:17:17
>>651
> その例でinterfaceの方にisDesignTime()を
> 追加するという仮定自体がそもそもありえないし
……。 isDesignTime() は元からあるメソッドですが。

671:649
07/03/15 10:23:39
>>670
おまえ逃げてないで俺の質問に答えろよ。

672:デフォルトの名無しさん
07/03/15 10:26:26
>>671
質問になってない。

673:649
07/03/15 10:31:39
>>672
答えになってない。

674:デフォルトの名無しさん
07/03/15 10:36:21
>>621
それだけじゃ解決しないね。

新プロパティ(dotでアクセス)と同名のフィールドが作れるなら
setter/getterのプロパティと同じ問題が起こるし、
C#みたく新プロパティと同名のフィールドが作れなくするなら、
標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。

これ以降は >>640 >>641 と同じ路線だな。
上記の書き換えを最小限に抑えようとすれば、
標準APIは極力新プロパティを追加しない方向になるだろうから、
新プロパティの構文は言語仕様に定義されたが、
標準APIで新プロパティが使えない、という本末転倒な事態が予測される。

つまり、使い勝手が悪い。

675:デフォルトの名無しさん
07/03/15 10:39:07
>標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。
標準APIが新プロパティを追加したら、
そのclass/interfaceを継承/実装して同名のフィールドを使っていたユーザコードの書き換えが必要になる。

676:649
07/03/15 10:42:44
やっとわかったよ。お互い説明が下手だと苦労するなｗ

677:デフォルトの名無しさん
07/03/15 11:02:59
>>675
まぁ、interface に「新プロパティ」を追加したら、
どっちみちそのinterface を実装しているクラスの書き換えが必要になる。
既存のコードは setter/getter は実装してても、
「新プロパティ」まで実装してて書き換えの必要がないってのは考えにくいから。

この書き換えを最小限に抑えようとすれば、
標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
以下、>>674 と同文、と。

678:デフォルトの名無しさん
07/03/15 11:15:13
> 標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
標準API は、既存の setter/getter を置き換えるものも含めて、
極力 abstract な新プロパティを追加しない方向になるだろうから

うーむ。既存の setter/getter は互換性のために残す事を想定してるから
置き換える、じゃないんな。まぁ、setter/getter を残しても残さなくても、
標準API に abstract な新プロパティを追加すれば同じだけど。

679:デフォルトの名無しさん
07/03/15 20:13:04
ゲーム関係に力を入れてけば自然とデスクトップ周りが強化されるからそっち系だな
OSを選ばないUDIライブラリとか、BGM周りはネイティブにディスパッチとかね。
標準であるかどうかってのがここらへんは大きい。

680:デフォルトの名無しさん
07/03/15 22:34:05
まずジョイパットか

681:デフォルトの名無しさん
07/03/15 23:05:33
ジョイパッドサポートは地味に大きいな

って10年前からいわれてるが

あとはJOGLも標準ではいってくれるといいのだが
今はプラットフォームごとに用意してあげないといかんからWindows以外はめんどくさい

本当は新世代専用GCコールもほしい
タイミングコントロールできて殿堂入りしないやつならアクション系もバリバリ使える

682:デフォルトの名無しさん
07/03/16 00:05:01
>>677
interfaceに追加したらそれを実装するクラスに影響があるのは、
「プロパティ」に限らず抽象メソッドでも同じだわな。

既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
↓
だから標準APIに「抽象メソッド」は追加できない
↓
「抽象メソッド」は標準APIに使えないから無意味

あほか。

683:デフォルトの名無しさん
07/03/16 00:22:54
>>682
> 既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
普通は、既存の interface に抽象メソッド追加するのは慎重にする。

逆に、今までにない interface を作る時は自由に抽象メソッドを定義できる。
> 「抽象メソッド」は標準APIに使えないから無意味
安易に追加できないが、「使えない」とか「無意味」とはならない。

abstract な新プロパティも、抽象メソッドと同じで、
今までにない interface を作る場合は自由に定義できるだろうけど、
既存の interface に追加する場合は慎重にならざるを得ないだろう。
既存の interface 経由で使えない事が予想される新プロパティは
「使えない」とか「使い勝手が悪い」と言える。

684:デフォルトの名無しさん
07/03/16 00:26:00
>>683
△既存の interface -> ○標準APIの既存の interface

685:デフォルトの名無しさん
07/03/16 01:10:18
java.sql.Connectionなんか増えまくりだった気がするが。
古い実装のを呼ぼうとするとErrorでも出るかな

686:デフォルトの名無しさん
07/03/16 01:11:37
>>683
既存のinterfaceを安易に拡張できないってのは当然だね。

>既存の interface 経由で使えない事が予想される新プロパティは

なんで新プロパティに限って既存のinterface経由で使われることを
期待されなければならないんだろう？

687:デフォルトの名無しさん
07/03/16 01:16:08
>>682
> だから標準APIに「抽象メソッド」は追加できない
> ↓
> 「抽象メソッド」は標準APIに使えないから無意味
ここで飛躍してる。基本的には「追加できない」==「使えない」とはならない。

で、setter/getter とは無関係な新プロパティシステムを導入したとして、
その新プロパティを、標準APIの既存の interface で使いたいと言う場合は
・新プロパティを追加すれば、その interface を実装していたコードを変更する必要が出る。
・逆に新プロパティを追加しなければ、標準APIの既存の interface では新プロパティは使えない

で、俺は標準APIの管理者は後者を選択すると予想するので、
その場合は新プロパティは「標準APIの既存の interface経由では使えない」ので
使えないとか、使い勝手が悪いと言えるだろう。
仮に前者を選んだとしても、コードの変更を迫られるので無問題とはならない。

688:デフォルトの名無しさん
07/03/16 01:23:35
>>686
> なんで新プロパティに限って既存のinterface経由で使われることを
> 期待されなければならないんだろう？
限って？他では期待されてないんだっけか？

689:デフォルトの名無しさん
07/03/16 01:27:18
>>688
限ってないよな。Closure だって、Closure Conversion とかで
abstract なメソッドが一つだけの既存の interface に変換する事を考えてたりするし。

690:デフォルトの名無しさん
07/03/16 01:48:55
URLﾘﾝｸ(blogs.sun.com) のリストとかを見るに、
たいてい inteface と関係ないか、既存の interface との協調にも配慮してあるよーな。

691:デフォルトの名無しさん
07/03/16 05:18:23
>>681
新世代・・・・ああああNewGeneration用のGCってことか。
いや、殿堂入りが無いというより、tenureの32をいじれるようになった方がいいかな。

ある程度、コア数が増えて並行処理が速くなると、OldGenerationを少なくして
Newgenerationのtenureを32回より多くして、NewGenerationで運用したほうが
効率いいと思うんよねぇ。
昔、24CPUのマシン使った時、10GB程度のNewGenerationをParNewGCかけてたけど
確か0.5s程、ホンの一瞬だった。

692:デフォルトの名無しさん
07/03/16 07:42:00
>>688
class定義に影響する新機能としては例えばfunction-typeなんかがあるけど、
じゃあこれは既存のinterfaceに追加されて使われることを期待されてるの？

693:デフォルトの名無しさん
07/03/16 08:53:05
>>688
対抗馬である setter/getter の syntax sugar なプロパティなら
既存の interface経由で使えるしな。

それと比較しても「使い勝手が悪い」といえるだろうね。

694:デフォルトの名無しさん
07/03/16 08:53:44
>>692
具体的に、どんな問題が出るんだ？

695:デフォルトの名無しさん
07/03/16 12:35:00
>>691
並列GCはデフォの状態よりスループットはいいけどレスポンスが大幅に悪化するぞ
あとGC稼動のタイミングをコントロールできる10msのGCとコントロールできない0.1msのGCだと前者のほうがいいわけで

696:デフォルトの名無しさん
07/03/16 13:50:53
>>695
今のマシンスペックならGCに0.1msもかからんよ。

ゲームならヒープサイズとスタックサイズの調整で2Dまでならストレスなく遊べる。
やっぱメモリ食いは収まらないけど。

取り合えずただのデスクトップツールとしては実用的じゃない？

ジョイパッド拾えるようになると同じ方向性で障害者用の入力補助装置の入力拾えそうでアクセシビリティ周りが格段に良くなって良いと思うけどな。

697:デフォルトの名無しさん
07/03/16 14:15:04
>>686
GCの時間はヒープサイズに綺麗に比例するのでなんともいえないよ

最近のマシン持っているけど0.5msきることは実際にゲームつくっていてまずない
新世代領域を少なくしてやっと0.2mくらいか

インクリメンタルGC（現在の実装は並列GC）だとレスポンス悪化してるし、
デフォのGCだとFullGCがいつかは必ず起きるし、おきたら使い物にならない

そもそもJava2DやJOGLなどライブラリによるGCはコントロールできなから
自分のコードでの調整は何も意味がない

0.1mが0.05mであっても同じこと

リアルタイム性ってのは早いかどうかじゃなく、コントロールできること、把握できることだから

698:デフォルトの名無しさん
07/03/16 15:41:40
>>571
まるでApache Antの記法だな

699:デフォルトの名無しさん
07/03/16 15:42:31
>>572
四項演算子か。

Checkstyleプラグインが警告しそうだな

700:デフォルトの名無しさん
07/03/16 19:54:46
>>693
既存のinterfaceに public int getHoge(); なんて追加したら
おんなじように「問題」は発生するが？

>>694
何の問題も出ないだろう。既存のinterfaceに追加したりしなけりゃ。

701:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/16 21:11:41
相変わらず説明が下手だな。

703:デフォルトの名無しさん
07/03/16 21:19:01
さすがに読解力に問題があるだろう。

704:デフォルトの名無しさん
07/03/16 22:07:53
>>701
>既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。

既存の「getter/setter」と関係ないプロパティが前提なら、当然既存のinterfaceにも
存在しているわけがないだろう。ここでアクセスしようとしている「プロパティ」ってのは
何のことを言っているんだ？
もし「getter/setter」のことならば、それはプロパティとは関係のない単なるメソッドだから、
普通にメソッドとしてアクセスすればよい。
もし新たにプロパティを追加することを想定しているのならば、それはインターフェースの
拡張に他ならないから、他に影響が出るのは当然。それは別にプロパティに限らない。

705:デフォルトの名無しさん
07/03/16 22:18:48
>>704
> ここでアクセスしようとしている「プロパティ」ってのは
当然、setter/getter と関係ない新プロパティシステムのプロパティ。
で、プロパティの持つものは、既存の setter/getter で表わされるのと同じもの。

プロパティ導入の大きな動機の一つに、setter/getter を宣言するのも、
呼び出すのも冗長だという不満を解消するというものがある。
setter/gettter とは別の新プロパティシステムを使えば、
既存の interface にある、既存の JavaBeans のプロパティに対して、
setter/getter を呼び出すのが冗長だという不満を解消できない。

仮に Tiger で追加された Generics が、もし仮に既存の Collection API と協調できず、
List でも Map でもパラメタ型を取れなければ、使い勝手が悪いと評価されるだろう。
それと同じ。

次ページ